Problem creating oblong sculpties

[Chosen Few]

---

Josh Susanto wrote:

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.

---

Oh, yes, of course it's possible.  No one ever disputed that (except maybe you).  You can use a texture that's already set up for counter-distortion (which is the case with most planetary map textures), or you can make sure the poles are each a solid color, or you can play with symmetry.  There are a plenty of ways to go about it.

However, I was under the impression when the subject first came up, that you'd required the ability to use just any old texture, as opposed to one specifically designed for the task.  If you're open to more advanced texturing options, then I'll happily tell you one of the very easiest ways to go about it with a bipolar sphere is simply to apply the texture to the existing default mapping (same mapping as a sculpty), and then take an extra 10 seconds with a 3D paint program like Mudbox or Zbrush or Photoshop Extended to heal the puckering with a clone stamp or healing brush.  It's literally two clicks. 

I believe Blender has 3D painting capabilities as well, although I haven't really looked into that.  Mudbox is my 3D painter of choice.

[leliel Mirihi]

---

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.

---

This seems to be the root of your misunderstanding so let me try to clear some things up. Textures are not pictures. Textures are not addressed by pixels. Textures are addressed with normalized floats in the ranger of [0,1]. Everything and I do mean everything about textures is interpolated, they go through some very heavy filtering before they end up on your screen. UV maps do not exist, they're a human construct to make the life of 3d modelers easier.

From the GPU's point of view objects are made up of a list of vertices, a list of texture coordinates and some other things we don't care about. The coordinates are matched one to one with the vertices, it doesn't matter what they are because quite honestly your GPU doesn't care. Each texture coordinate is completely independent from the others, the texture coordinates for two triangles can overlap or cross in the texture space in any way that you can come up with, because one again your GPU doesn't care, each triangle is considered to be independent.

 

[Drongle McMahon]

Well, your globes still have a relected symetry. As you seem so hard to convince, here is a sphere with no symetry at all and no pucker. The picture shows the same sphere six times, top withpout UV map superimposed, bottom with it. The map is tthe same as the square one I dod before, but with the two halves of the sphere beside each other instead of on top of each other. There are no unused parts of the texture. Left-to-right are first views of the two poles, then one of the equator. Underneath are closeups of the poles.

PS. I turned the displacement opff for clarity. I suppose you will now tell me that isn't what you wanted to see.

[Kwakkelde Kwak]

Hell it happened again, a post that took well over an hour destroyed.....

[Kwakkelde Kwak]

---

Josh Susanto wrote:

>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?

---

That depends on how you use your textures. If you don't use a repeat on your textures so every pixel will show on a non hidden surface, you have useless data. Other than that, yes.

---

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.

---

Difficult to answer, since a mathematical surface isn't neccecarily the same as a triangular polygon. I'll try to show the different possibilities for some shapes, including the tetrahedron and the box. I'll go with the shape resulting out of intersecting two identical objects, with the most visible unique surfaces as a result. First the number of unique mathematical surfaces for the two single objects against those on the two intersecting ones. Second the number of triangles needed in 3D modelling to make the original two shapes against the number that's needed to build the combined object without any hidden structure.

tetrahedron: 8 to 24 (1:3) and 8 to 24 (1:3)

4 sides pyramid 10 to 32 (1:3.2) and 12 to 32 (1:2.67)

5 sides pyramid 12 to 40 (1:3.3) and 16 to 40 (1:2.5)

8 sided pyramid 18 and 64 (1:3.6) and 28 to 64 (1:2.3)

cube 12 to 42 (1:3.5) and 24 to 51 (1:2.1)

Let's not focus on the mathematical numbers, which are clearly in favour of anything besides the tetrahedron,  but on the 3D modelling ones on the right. As you can see the tetrahedron indeed has a better ratio than the cube, so one would guess that's the best option. However, on hard edges the vertices aren't shared between the different faces so we need to look at something else.

Now look at the number of triangular faces the objects APPEAR to have. two tetrahedrons seem to have 24, two boxes seem to have 51, which is more than twice as many. We already established a tetrahedron has 12 vertices according to SL (4 faces with 3 vertices each) when the edges are hard. This is exactly half of the 24 vertices for a cube (6 faces with 4 vertices each). I think math gives us a winner here and it's not the tetrahedron. (I can't predict what will happen if we intersect 3 or more objects, but my intuition says the difference will get bigger with every object added. Please don't ask for the math on this, two was a pain already)

Hmm, forgot one thing, that is SL rendering cost is NOT the same as GPU rendering cost, which to my best knowledge is based on the number of normal triangles facing the screen. For a cube that is a minimum of two and a maximum of six. For the tetrahedron that is a minimum of one and a maximum of three. Again that exact factor two. Seems the way rendercost is calculated by SL isn't so dumb....

 

I ran out of brain for today for this post....I'll answer the rest later.

[Josh Susanto]

>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.

Yeah. I better not build with domes or cylinders, either. Too much calculus.

>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.

That's a thought. I still don't know if we save any data by leaving textures blank for objects we are going to make maximally shiny.

(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.

I didn't think so. But it would have been fine if you were. "Better" without any context is a pretty broad subject.

(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....

Since that's now come up, I might explain that I do most of my work with a baby on my lap. And I actually get even less done when my wife is in charge because taking care of a baby is half as much work as helping her take care of a baby. A reason I probably should have acknowledged earlier for making a bunch of 1-prim sculpt rocks is that I can more often than not at least finish some complete step of the process without someone in my home creating an excuse to make me stand up and step away from the computer. I can't normally watch a tutorial example to completion without backing it up at least twice. Not everyone has these kinds of creative challenges, I know. But whether or not some technology can actually allow and real progress with the work divided into periods of a minute of or less is a very real question for at least some users. I have had to stand up once while writing this paragraph, for example. And I have to stand up again before I continue. 

>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.

If there's no way to do at least simple conversion that's going to slow me down a bit. If I do convert, I won't be very interested in working on the things as a sculpt. I can already do with sculpts almost anything sculpts will do. As for what sculpts are and what they are not, SL thinks my sculpts are 2048 faces, but the data says otherwise. The data says they have 32768 faces. I have been under the impression that might actually be plenty to play with in terms of producing more intelligently mapped meshes with 2000 or fewer faces, but I suppose it's possible I've been mistaken. What happens if I just press the smooth button 1 time?

>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.

My exceptions were stictly to address the possible process of converting existing sculpts to mesh. With the sculpt data I already have, it should be possible to make immediate improvments in the shape of the object simply by no longer ignoring 15/16 of the existing data. Better might be better, but I don't know how much better something would necessarily have to be.

>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.

This is valuable information to me if it means I can start applying the thing I need to apply sooner rather than later. Thank you.

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

What's the practical consequence of such screwing up, generally?

[Josh Susanto]

> 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.

Then why are the data costs really so similar for similar sizes and shapes ("similar" meaning, not off by maybe more than one decimal point)?

You can probably see why I've been suspicious of the claimed greater efficiency of mesh for a lot of equivalent sculpt items. 

But I hadn't considered compression. Does the compression explain it?

 

[Josh Susanto]

>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.

The dead parts of oblongs baked down with the prim oven appear to be all the same color. 

I'm not endorsing that as a solution; I'm just pointing out that it appears to be maybe less of a problem than it otherwise might be.

[Josh Susanto]

>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.

VERY clear. Thanks.

>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.

Some redundancy is subjective and contextual, such as the question of whether a specific thing should really be resolved at increments any smaller than 256 of the maximum (and sculpts have their own, other, different redundancies, I know). But there's some redundant redundancy here, too. If not in the 3d modeling app (where I understand potentially nothing might be redundant for some particular use), then within the data actually trying to make its way to my monitor.  What explains the comparatively similar data costs of the two media for a similar object? I already asked about compression. Is there anything else to which there might be some practical point for me to consider in optimizing data budgets?

>Since sculpty texture positions are immutable, there is little point in discussing their accuracy,

They are immutable in terms of the way they will be expressed with a specific piece of data, yes. But as SL ignores no less than 3/4 of the data, and, in my case, as much as 15/16 of it, texture positions are not actually immutable upon editing. They just don't like to be moved very far.

>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.

Understood.

>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.

So it matters a lot when it matters, but it rarely matters? That works for me.

I'd like others reading this to try to understand that just because I'm cynical about mesh doesn't mean I'm not cynical about sculpts and other prim types. I think this is actually clear from re-reading the earlier messages, but it could have been a little clearer, so I'm saying it now. 

[Josh Susanto]

>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.

And yet, no outrage. Hmm.

>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.

But this is a distinction that could arguably be done away with, technically... no?

 >A three button mouse is a standard requirement for most 3D modeling software.

I'm going to get one because I do think it would be a good investment. But I haven't seen one since I moved to South America 2 years ago, and I've never needed one for anything before, ever.

>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.

I have a Sony Vaio that's less than 2 years old. It has 2 buttons, as do the mice that are sold for use with it. OTOH, it has the side number pad, so that's a bit of a work-around for a while anyway. AND I have this key, standard: ñ.

>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.

Sounds fun. Does Maya recommend buying these things before buying Maya?

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

In that case, I'd be facing a lot of extra work. But a large part of the shape can be a small part of the map and vice-versa. The pixels will just come out on the surface at very different sizes. I made a cup sculpt as an exercise at one point, for example. Most of the map is the handle, and the body of the cup is a tiny region right at the center of the map. Pointless? Maybe. But SL didn't have mesh yet, and it was becoming less and less clear to me that it was going to on any practicable time frame. 

>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.

I'm not disagreeing with these statements, actually. I'm just adding qualifiers as a sort of caution against overstating the value of the principle. Meshes are a better way to make a lot of things. But not necessarily if the process actually becomes more complicated for a comparable result. Producing the sculpt cup, for example, was more efficient than waiting for SL to implement mesh. Now that mesh is here, it's a different question. It includes things like how easily I'll be able to get a 3rd mouse button, and how easily I can do how much in the meantime. 

(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.

If this is your way of saying that the base resolution is higher than I would ever need to consider, that's a point I can take to heart.

>Soft normals are marginally cheaper than hard ones.

This is VERY important information. Especially as I would have expected something like the opposite to be true.

>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.

With current product, I have to give some thought to whether to sell it at full bright on or off, but I do that without considering data costs. How will the normals be likely to change the way I look at this part of the process?

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

That's OK. Just knowing which way I should prefer to default is probably enough for me to consider, unless the math is really, really important. 

 >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.

Good enough, thanks.

>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.

Such as putting a vertex where a similar visual corner can otherwise be formed by the intersection of two solids, for example?

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

You know I always assume exceptions exist. But a regular sculpt cube has a buncha'  triangles on it basically just as a convenient way to spread pixels around. I can see that's not very efficient, and it's one of the reasons I never really like sculpting things with a lot of flat face space. If I want to be redundant about something, I'll choose something about which I can be very conspicuously redundant.

>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).

True. If I wanted anything that regular in shape, I would sculpt it first and then edit a texture to fit it. But since that's what most other sculptors do, I wouldn't see any reason to try to compete with them by using that approach. You might have an even harder time getting such people to try working with mesh, given the much lesser creative challenge of simply cutting a texture to fit an existing sculpt.

>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.

I think I've already been doing that. Sculpts are just a comfort spot because they were easy right from the start and have stayed easy, and because people keep buying them. I'm actually quite enthused by the idea of finally making some tetra-focused constructions just to see how low I can get prim equivalency counts on functional objects. 

(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.

They're locked on any particular sculpt map, yes. They can be moved around a bit on a different map if the first map is large enough, but I agree it's quite limited.  Going from a 128 limit to a 1024 limit actually never sounded that helpful to me, but if the limit is as much larger as I now know that it is, things now become more interesting, at least over the long term. 

>The vertices themselves are less important in this context than what happens in between them.

That would seem to be true regardless of the medium.

>So, it's never about having or not having an infinite number of vertices.

The number of possible vetices is actually a real question for me, since I already chop up sculpt maps, and I'd like to be able to go a lot further with the chopping; if not with sculpts, then with meshes. 

>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.

I can assign any specific sculpt data point to anywhere between (0,0,0) and (255,255,255). I just have to use exactly the same number of data points for every sculpt and the shape doesn't get any more refined than that. For rocks, this has been pretty sufficient. But I should like to make a little more than rocks eventually.

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

I can aslo make any portion of my sculpt map any one color.

But now I'm curious.... why would I assign more than one UV point to a mesh vert?

 

 

[Chosen Few]

---

Josh Susanto wrote:

 

And yet, no outrage. Hmm.

---

From whom?  Me?  You?  The general public? 

I'm not "outraged" over anything we've talked about.  I think it's unfortunate that due to some shortsighted thinking way back in the beginning of SL, there's now so much common misunderstanding of what's really important in any 3D simulation.  I also find it more than a little silly that certain people, upon being shown that their assumptions were incorrect, stubbornly cling to their misconceptions, no matter whether they jive with the facts on the ground or not.  Human beings are funny creatures.

But none of that is fuel for outrage.  Why should I have any emotional investment one way or the other in the plain and simple fact that a cube with 108 triangles happens to be artificially given the same value as a torus with 1152 triangles?  If I'm going to expend outrage anywhere, there are much bigger fish to fry in this life than the manufactured measurment units of a virtual world platform.

The biggest reason the general public is not outraged by these things is because they're completely unaware of them.  Most people don't know or care in the slightest degree how these things work.  The fact that you and I are even having a conversation about it puts us is in the "you could count 'em on one hand" category, compared with the rest of the gamer/virtual world user population.

So that just leaves you.  I don't pretend to have any incite on what you might or might not be outraged about.

 

---

Josh Susanto wrote:

 

But this is a distinction that could arguably be done away with, technically... no?

---

Sure, it could be done away with.  But it never WILL be done away with, because to do so would be to break existing content.  As I've said quite a few times now, unless we start over with a brand new virtual world that is not the SL we've known for the past 8+ years, the accounting rules we've always had for prims and sculpties will always remain the same.

If it were up to me, I'd do away with the old rules right now, and deal only with the real numbers.  But fortunately for most of the SL poulation, it's not up to me.

 

---

Josh Susanto wrote:

 

I'm going to get one because I do think it would be a good investment. But I haven't seen one since I moved to South America 2 years ago, and I've never needed one for anything before, ever.

---

Ah, South America, famous breeding ground of two-button mice.

Seriously, you'll have to forgive my ignorance of the offerings in your country, and your continent.  The countries I can think of off hand in which I have clients and colleagues are the US, Canada, UK, Germany, Russia, India, China, Japan, Indonesia, New Zealand, and Australia.  Every one of them has had the same standard of access to all the same hardware and software that I have.  It just never occurred to me that something like a 3-button mouse might be an unusual item anywhere in the computer-using world.  But hey, I'm just a fatcat American, right?  What do I know?

In any case, I do hope you won't have much trouble obtaining what is a $5 item here.  If you do, let me know, and I'll send you one.  You can reimburse me with an equivalent value in $L, if that's easiest for you.

 

---

Josh Susanto wrote:

 

I have a Sony Vaio that's less than 2 years old. It has 2 buttons, as do the mice that are sold for use with it. OTOH, it has the side number pad, so that's a bit of a work-around for a while anyway. AND I have this key, standard: ñ.

---

Trackpads on laptops do tend to have just two buttons, yes.  But considering it's nearly impossible do 3D modeling with a track pad in the first place, it's kind of a non-issue.  My current laptop came with a nice 5-button Razer mouse, which is cool.  With my previous one, I just used a cheapo wheel mouse that came with my way old Dell desktop.

As for the side number pad, some people consider that a really nice feature on a laptop, and if you're one of them, then it's great that you have that.  Me, I really hate laptops that have them.  The rest of the keyboard has to be off center, to accommodate the space the number pad occupies.  This not only disturbs my calm just by looking at it, but more importantly, it hurts my back after a while, having my hands off kilter like that.

Even on my desktop, my keyboard doesn't have a number pad. I hate that they put the damned thing on the right, which means you have to reach over it to get to the mouse. It's a design that came about long before the mouse was ever invented, and for some silly reason, it's stuck.  I can't imagine it would be a tremendous feat of engineering to move it over to the left where it now belongs.  

My desktop number pad is a standalone accessory, made by the same company that makes my keyboard, and I park it on the left.  Keyboard in the middle, mouse on the right, number pad on the left, all is right with the universe.

If you're at all curious, my keyboard is the  adjustable folding kind from Goldtouch.  I had really bad wrist problems a few years back.  Doctors said surgery; I said new keyboard.  I reasoned that the best way to heal a repetitive stress injury was not to cut it open and dig around in it, but simply to take a way the repetitive stress that caused it in the first place.  It turned out I was absolutely right.

The folding keyboard keeps keeps my hands in a neutral position all day long, so there's no stress, and because it's adjustable, I can change things up every now and then, to avoid too much repetition.   End result, my wrists have been pain free good five or six years now.  That thing was a godsend.

 

---

Josh Susanto wrote:

 

Sounds fun. Does Maya recommend buying these things before buying Maya?

---

Maya requires a three-button mouse (unless you want to remap the controls, which you CAN do). 

As for the Wacom tablet, Maya has support built in for making use of its pressure sensitivity, as do most high end graphics programs.  I don't know that Autodesk actively recommends it outright for Maya, but the included support certainly serves to imply it's a good idea to have one.  They do actively recommend it for Mudbox.

 

---

Josh Susanto wrote:

 

If this is your way of saying that the base resolution is higher than I would ever need to consider, that's a point I can take to heart.

---

No, it's my way of saying that "resolution" in the way that you're thinking of it doesn't even apply.  There's an entirely different set of principles in play.

For years, I warned people about exactly this situation.  Whenever anyone would ask about how to learn to use 3D modeling software in order to make sculpties, I always said, "Learning to make sculpties won't help you to make arbitrary 3D models, but learning to make arbitrary 3D models WILL help you to make sculpties.  Don't put the cart before the horse."

It's a bit like trying to teach someone to drive stick after they already know how to drive automatic.  If you learn stick first, automatic just comes naturally.  However, if you start with automatic, then stick seems foreign, uncomfortable, and far more complicated than it actually is.

By the same token, if you already know how to mesh model, sculpties are a total no-brainer, easy as pie.  But if sculpties are all you know, then mesh seems foreign, uncomfortable, and more complicated than it really is.

People who took that advice are now in a position to make whatever they want.  People who didn't are in the boat that you're in, having to unlearn the things they thought they knew.  That's a hard thing to do.

Interesting bit of trivia for you:  It actually takes more chemical reactions in the brain to forget than to learn.  This is why first impressions are so powerful, why preconceptions are so hard to dispel, and why habits are so hard to break.

 

---

Josh Susanto wrote:

 

This is VERY important information. Especially as I would have expected something like the opposite to be true.

---

It's important, yes, but not in the way you're probably thinking right now.  From edge to edge, there's no discernible detrimental effect of a hard normal, or beneficial effect of a soft normal, in terms of performance at the rendering level.  A model with all hard normals will draw just as easily as one with all soft normals.

What's IS crucially important is the fact that soft normals are far less costly than triangles.  Soft normals on small number of edges can replace a great many polygons, when the goal is to create the appearance of a smoothly curving surface. 

For example, one of the cylinders below has just 10 sides (just like the avatar's legs and arms), while the other one has 24, like an SL cylinder.  With the hard edges of the tops out of frame, and only the softened edges of the sides in view, can you tell which is which? 

If you look really closely, you MIGHT notice a slight difference between the two.  But unless you actually know what to look for, you'd never know that one is barely half as round as the other.

The key to effectiveness in low poly modeling arguably lies in the normals, more than any other single factor.

 

If you want to know just how powerful this can get, its zenith lies in what's called normal mapping. Take a look at the image below. 

As you can see both planes have the same geometry, just a single quad.  That much is obvious.  But would you believe both planes also have the exact same texture one them?  Well, they do.

Here it is:

 

So, why does the plane on the left look like the cratered surface of a moon or an asteroid, while the one on the right just looks like cloudy smoke rings?  The reason is the plane on the left has a normal map applied to it, while the plane on the right does not.  Here's the normal map:

Look familiar?  It should.  Normal maps follow basically the same logic as sculpt maps.  They just govern the directions in which light bounces off a surface, instead of controlling the positioning of vertices.

With a normal map a applied, a low poly surface can look incredibly complicated, as if it's got thousands of times more polygons in it than it actually has, and a simple texture can look exquisitely detailed, all for very little cost.  It's a fantastic technology, which most modern game engines do support.  SL doesn't support it yet, but it will.

In the mean time, SL does have the ability to utilize hard and soft edge normals, which can be quite powerful in itself.

 

 

---

Josh Susanto wrote:

 

With current product, I have to give some thought to whether to sell it at full bright on or off, but I do that without considering data costs. How will the normals be likely to change the way I look at this part of the process?

---

The first thing to understand is that full bright doesn't affect the data cost in any way.  It's a post processing effect, applied after all the data has already been delivered.  So, if data is your only concern, it makes no difference.

What it does make a difference to is the render process.  If my understanding of how full bright works is correct, full bright will speed up the rendering, since shading calculations don't need to be done.  I could be wrong about that, though.  It's possible all the same calculations take place either way, and they just happen to all arrive at the same number when full bright is applied.

I'd be curious to hear Drongle's input on this.

 

 

---

Josh Susanto wrote:

 

Such as putting a vertex where a similar visual corner can otherwise be formed by the intersection of two solids, for example?

---

Not necessarily. There are cases in which you'd want extra vertices at the intersection.

For example, if either or both of the solids is using tricks of light (soft normals) to appear more rounded than it actually is, the intersection will destroy the illusion.  Thus, some extra vertices to help define the specific intersected shape you want to illustrate can help a great deal.

Also, depending on the particular lighting scheme in play, the presence or absence of vertices can greatly affect the overall appearance of objects.  This is why SL cubes, for example, have three times as many vertices per face as they need for their shape.  SL originally used vertex lighting.  Cubes would have appeared very dim in the middle without the extra vertices.  Older viewers still employ the old lighting scheme.  Until those are all out of use, cubes need to remain more poly-heavy than they otherwise could be.

 

 

---

Josh Susanto wrote:

 

You might have an even harder time getting such people to try working with mesh, given the much lesser creative challenge of simply cutting a texture to fit an existing sculpt.

---

People's internal stubbornness aside, the fact is moving the UV's around to fit a texture is very often MUCH simpler than altering a texture to fit a fixed UV map (assuming you're doing both by hand), especially on a low-poly model.  SL users have been going about it so bass ackwards for so long, they have no idea the undue suffering they've endured all this time.

 

---

Josh Susanto wrote:

 

The number of possible vetices is actually a real question for me, since I already chop up sculpt maps, and I'd like to be able to go a lot further with the chopping; if not with sculpts, then with meshes.

---

If the number of possible vertices so vitally impotant to you, then the answer is SL allows up to 65,536 vertices in a single mesh.

Your premise for even pondering that is entirely flawed, though.  There's no need to "chop" anthing at all.  If you want a mesh model to have a particular shape, you just give it that shape, fluidly, right from the start.  Use as many vertices as you need in order to define that shape, no more, no less.  The only thing to be gained by continuing to think of it in terms of map-like resolution and such are headaches.  You're thinking about all the wrong things right now.

 

---

Josh Susanto wrote:

 

I can assign any specific sculpt data point to anywhere between (0,0,0) and (255,255,255). I just have to use exactly the same number of data points for every sculpt and the shape doesn't get any more refined than that. For rocks, this has been pretty sufficient. But I should like to make a little more than rocks eventually.

---

You really need to stop comparing things that have no basis for comparison.  Until you let go of your sculpty-centric thinking, and start completely over, you'll never be able to comprehend what I've been trying to tell you.

 

---

Josh Susanto wrote:

 

I can aslo make any portion of my sculpt map any one color.

---

What does that have to do with anything? 

From that statement, I can only conclude you still don't have the faintest clue what I'm talking about.  At this point, I have to cede that no amount my saying, "No, that's not what I mean," or "No, there's no way to compare ______ with ______," is going to get you there.  You're just gonna have to do it to understand.

 

 

---

Josh Susanto wrote:

 

But now I'm curious.... why would I assign more than one UV point to a mesh vert?

---

Let's go back to the avatar as an example. Take a look at the image below.  See the little yellow dot on the avatar's shoulder?  I've drew a big red arrow to point at it.  That's a selected vertex. 

Now look at the UV map on the right hand side of the image.  Notice there are three such yellow dots.  I've got arrows pointing at those, as well.  Those are all the same vertex.  It has to exist in three places on the UV map, because that vertex happens to be a place where three UV shells meet.

Remember I said there vertices themselves are not as important as what's going on in between them.  This is an example of what I was talking about.  That one vertex marks the intersetction of four quads.  Two of those quads are on the avatar's arm, one is on the front torso, and one is on the rear torso.

If I paint a circle around that vertex, half of it will appear on the arm, one quarter of it will be on the front torso, and one quarter will be on the rear torso. See:

Because that one vertex is represented by three different UV points, three completely different areas of the texture can be brought together to form a single picture on the model surface.

Any time you divvy up the UV's into more than one shell (or "island" as they're called in Blender lingo), all the vertices along the seams will have more than one UV point.  The vast majority of 3D models in existence have more than one UV shell.

Even for models that only have one shell, though, you're still going to have vertices represented by more than one UV point.  For example, here's the mapping for a default cube:

As you can see, the selected vertex is represented by two UV points.  In fact, so is almost every vertex on the whole cube.  There's no way to unwrap a cube into six discrete rectangles without repeating vertices on the 2D canvas.

 

I don't know that any of this is making sense to you yet, without your having ever UVed so much a single polygon.  Again, you're really going to need to start doing it before you'll really get it.  Even if you think you get it right now, you most likely don't really.  Get that mouse, start doing these things yourself, and then we can have a much more intelligent conversation.

[Chosen Few]

---

Josh Susanto wrote:

>

 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.

Then why are the data costs really so similar for similar sizes and shapes ("similar" meaning, not off by maybe more than one decimal point)?

You can probably see why I've been suspicious of the claimed greater efficiency of mesh for a lot of equivalent sculpt items. 

But I hadn't considered compression. Does the compression explain it?

 

---

 

I don't want to steal any of Drongle's thunder, but I will point out that you'd do well to notice the specific wording to which you replied, before you read more into it than is actually there.  Drongle specifically mentioned downlaodable data per vertex, which is only one factor among many, many, many others that add up to determine the actual total costs.

Since it happens that the knowledge of how to draw every possible sculpty is already hard coded into the viewer, the only data that needs to be downloaded is a set of three eight-bit numbers for each vertex.  We use RGB images as the container vessel for those numbers, since it happens that RGB channels fit that same eight-bit description.  But as you know, not every pixel in those images gets used, which means there's autmatically a drastic increase in the total amount of data transferred, as soon as you step back from the per-vertex level, to look at the whole thing.

Also, because you cannot control the UV layout, the normals, the number of materials, or even the basic geometric structure of a sculpty, there's that much less data to have to transfer.  But is it fair to call a lack of options a savings?  I really don't think so.  Does a home run hitter save on running because he doesn't have to run around fourth base?  It's hard to save on what isn't possible.

Arbitrary meshes cannot be hard coded in advance the way sculpties are.  That's why they're abritrary.  Hence, there's a whole lot more that needs to be described.  First, how many vertices do you have, and where are they?   Second, what triangles do those vertices outline?  Third, what texture coordinates (UV points) correspond with those vertices, and what are their values?  Fourth, for each edge that runs between every pair of vertices, are the normals hard or soft?  Fifth, how many materials are we talking about, and to which trianges are each of them assigned?  Etc., etc., etc.

Now perhaps you're getting some inkling of why it was such a challenge to get arbitrary mesh support to work in SL at all.  To transmit that kind of information within just a few seconds, and then draw it all on the fly, is no small task.  It took years to figure out how to make it work.

 

I'm far more concerned with render costs than download costs.  No matter how long an object takes to download, it only has to happen once, and then you've got it, until you leave the scene.  Rendering has to happen every frame.  If an object is hard to render, your frame rate goes way down. 

Most sculpties are harder to render than they need to be, for their shape.  That's not necessarily true of a lot of your relief sculptures, but it's usualy the case for most other types of items that tend to be made from sculpties.  Nearly all could be more render efficient as aribtrary meshes, whether or not they're more download efficient.

[Drongle McMahon]

"I'd be curious to hear Drongle's input on this."

I'm afraid I am blissfully ignorant when it comes to ther internals of the gpu, or even of opengl. So I can't help you there. For example, I wondered whether faceted mesh, depite their higher download weight from having more normals at each vertex,  would be cheaper to render bacuse the normals don't need to be interpolated between the vertices. Runitai (aka davep) explained that on the contrary they were more expensive for rendering too. The reason was something to do with freqency of internal vertex cache misses in the gpu memory when there were more normals. Its a very long time since cpus became too complicated for me to think about their insides, and I guess gpus are more complex by at least an order of magnitude. Fresh unused neurones are required for that sort of thing.

[Josh Susanto]

> a clone stamp 

Uh, thanks but no thanks.

My own seamless textures have their own quirks, but seeing how Photoshop users tend to create them, I'm happy without cloning and liquefication and such.

There used to be some free sites online that would do polar coordinates and such, but they have a tendency to get disabled or shut down after some small number of months. 

I've especially been frustrated that I can no longer turn a square into a circle, rotate it 45 degrees and then resolve it back into a square.

Pending things like that coming back at some point (or me being able to pay for them) I'm not really interested in working with biplolar spheroids. I only used a regular prim sphere in the earth map example to be extra ironic.

[Chosen Few]

---

Josh Susanto wrote:

>

 a clone stamp 

Uh, thanks but no thanks.

---

Have you ever actually used a cloning tool, Josh?  It sure doesn't sound like it.  Sorry, but commenting in such a way on something you don't know how to use is just idiotic. 

Do we now need to have a week and a half long discussion on the merits of clone stamping before you'll be convinced that in the hands of someone who knows how to use it, it's fantastic tool, or will you just take my word for it?

 

---

Josh Susanto wrote:

My own seamless textures have their own quirks, but seeing how Photoshop users tend to create them, I'm happy without cloning and liquefication and such.

---

I don't know what it is you think "Photoshop users tend to" do, but obviously it's not positive.  Perhaps I should remind you that I AM a Photoshop user.  Should I be offended by whatever it is you're implying?

Photoshop is the single most important tool I own.  You'd be hard pressed to find a professional digital artist on this planet who wouldn't tell you the same thing.  If you've seen anybody get crappy results with Photoshop, it's because they're a crappy artist.  It's not because of the tools they're using.

 

 

---

Josh Susanto wrote:

There used to be some free sites online that would do polar coordinates and such, but they have a tendency to get disabled or shut down after some small number of months. 

I've especially been frustrated that I can no longer turn a square into a circle, rotate it 45 degrees and then resolve it back into a square.

---

IGIMP and Paint.Net are both free, and are both excellent.  Paintshop Pro is very inexpensive, and is also a fine choice.  All three can do what you're talking about.

 

---

Josh Susanto wrote:

Pending things like that coming back at some point (or me being able to pay for them) I'm not really interested in working with biplolar spheroids.

---

If you're still talking about rocks in particular, then I'd say that's a good thing.  There are much simpler ways to go about making rocks.

 

---

Josh Susanto wrote:

I only used a regular prim sphere in the earth map example to be extra ironic.

---

I'm afraid whatever irony you were going for was lost on me.

[Chosen Few]

---

Drongle McMahon wrote:

"I'd be curious to hear Drongle's input on this."

I'm afraid I am blissfully ignorant when it comes to ther internals of the gpu, or even of opengl. So I can't help you there. For example, I wondered whether faceted mesh, depite their higher download weight from having more normals at each vertex,  would be cheaper to render bacuse the normals don't need to be interpolated between the vertices. Runitai (aka davep) explained that on the contrary they were more expensive for rendering too. The reason was something to do with freqency of internal vertex cache misses in the gpu memory when there were more normals. Its a very long time since cpus became too complicated for me to think about their insides, and I guess gpus are more complex by at least an order of magnitude. Fresh unused neurones are required for that sort of thing.

---

Ah, OK.  I didn't realize it was outside your area of expertise.  I just kind of figured you were the go-to guy on all things sciency like this.

[Kwakkelde Kwak]

Ok, third try...sigh

---

Josh Susanto wrote:

Viewing constraints as challenges is

creative thinking.

Are you sure we really want to go there?

---

I'm a designer, I wouldn't feel out of my element discussing creative thinking. To answer the question though...no, for the sake of the SL Building and texturing forums.

---

I think igloos might be faster and easier.

---

No you don't:)

---

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.

---

Two tetrahedrons won't build you a desk with anything but a triangular top. I'm starting to wonder if you understand what a tetrahedron is and what its possibilities and limits are.

No room for your legs? Hang it from a wall, voila. Yes you can do the same with a single tetrahedron, but that still gives you a triangular top.

Try to stop thinking in prims, but in 3D surfaces, I can't say this often enough. For some reason you take the freedom to move around the vertices on a tetrahedron if that suits your needs, yet you say a box is a box. You can move vertices on a box around aswell. It would no longer be a geometrical cube, but it would be the same as far as your graphics card is concerned, or the SL rendercost calculation, well almost anyway.

Math? I think I covered that, at least superficially

Practical desk? I think I hear wings flapping.

---

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

---

A bounding box matter because most SL objects are square or squarish. So on the xy projection of the bounding box (which can be anything between 0.01 and 64 meters) any unused space is often lost. Boxes use the entire area, tetrahedrons only half.

---

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.

---

A box will give you 100% desk area. How will one, two three or infinite tetrahedrons give you more than 100%?

Again, why can you move around verts on a tetrahedron and not on a box? You can make trapezium shaped desks with a box.

---

Bingo.... I think.

---

Think again. combining two tetrahedrons into a four sided pyramid is the same as welding the top vertices of a box together.

Stop thinking in prims for crying out loud:)

---

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.

---

Hmm, what shall I say? Ah..stop thinking in prims! If you want a good low data base shape for mesh construction, use a triangle, as many as you need. No more no less. You can make any shape with them, or fake one anyway, that's what polygon or mesh modelling is afterall.

---

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.

---

Yes there always has to be some element that can take pressure rather than tension. But you can keep this to a minimum. Take a spoked wheel apart and you'll have yourself a bunch of very wobbly elements.

A microthin tetrahedron is effectively a plane. How are you going to fill something that has no volume? (Not to mention why)

---

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.

---

Bucky Fuller, does that ring a bell?

I think people use domes in SL because they like the shape, nothing more, nothing less. Nothing compulsive about it. Anyway, those domes are made out of triangles anyway, as far as all your soft- and hardware are concerned.

---

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.

---

Not entirely sure what you mean, but if you mean a blank space on a sculpt map is by defentition wasted data and using all the space is not, I think the Drongle experiments with compression might tell you something different. If you use half the sculptmap for your shape and the resulting map is less than half the data (bit-wise). Not sure about the numbers on this at all though. It doesn't matter to begin with since you already acknowledged meshes are preferred in most cases.

---

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.

---

You won't. Picture a 100 meter long room. Place a plane in the middle of that room, dividing it into two. You have two 50 meter rooms. You can't honestly claim you can see the difference between a 49.9 or 50 meter long room. You'd have to either measure it or rotate your camera through the wall, in which case a "solid" wall wouldn't look so solid either.

---

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

---

In RL a 10 cm thick wall can take tons of pressure, a 10 cm ceiling would need a huge construction to keep it from collapsing. I recognise that immediately, without thinking about it. I know others don't, so to them it looks believable. That apparently includes you.

As long as there are no holes in the ceiling for stairs or skylights, you can use a plane just aswell as you can for the wall I described, I won't notice.

[Kwakkelde Kwak]

Can I be superannoying and point out these two UV points aren't duplicated anywhere? (green arrows)

[Chosen Few]

---

Kwakkelde Kwak wrote:

Can I be superannoying and point out these two UV points aren't duplicated anywhere?

---

Sure, as long as I can be superannoying, and point out that two tetraherdons could build you a desk with diamond-shaped top.

I'm of course in complete agreement with everything else you said, regarding Josh's present fascination with tetrahedrons.  The fact that he referred to a two-tetrahedron desk as "practical" does beg the question whether he understands what tetrahedrons actually are.  I certainly wouldn't want to sit at that desk.

 

Anyway, good catch.  I've edited my post.

[Kwakkelde Kwak]

The thing you built is what I think Josh has in mind. It's standing on two points though. You need at least three to keep it balanced. I know SL has no gravity or other force unless you assign them by script, but following that logic one can also make a hovering box.

Good luck explaining UV btw. I hope Josh and others read it carefully and pick up some things along the line,even if they don't fully grasp it.

[Kwakkelde Kwak]

Replying to myself here... the intersecting boxes don't have 51 apparant faces, but 48, I already thought this was an unusual number.... still, exactly twice as many as for two intersecting tetrahedrons.

I uploaded a bunch to SL and I am getting strange figures on them. I'll have to take a look at the algorithm, but the displayweight according to SL is 314 for 8 tetrahedrons at 8 x 8 x 8 meters as bounding box and for cubes with the same setup 419.

I uploaded with the full model for all LODs.

I'll have to figure out what exactly it is I am looking for here:)

[Josh Susanto]

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

>Nope.

I created this to see if would work as a template, but I didn't like the effects it produced, so I just decided to sell it as sort of a joke...

 

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

Without fractals or something similar, there will always be a fixed resoltution. It might just be too high to matter, as I now understand it probably always would be with mesh.

 (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?

I think I'd better just accept that I'm not capable of communicating this idea correctly; that is, unless anyone else is not confused about what I've been asking.

Anyone?

(

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.

I guess there's not really anything for you to look at, because the sphere you were using doesn't use the whole image, no matter how that image is rearranged, and, no matter where you set the visible limits, at no point will they be shown as tangent to the opposite edge.

As long as I wouldn't have to see the equator, I guess that wouldn't matter. But, in that case, I might as well just make a half-spheroid and expect the absence of the other half to be hidden, rather than just a pucker.

 

[Josh Susanto]

>"This seems to be the root of your misunderstanding... each triangle is considered to be independent."

The explanation is simpler than that, I see now.

1)

The mushroom didn't load out as a 128 .obj.

It loaded out at the resolution Cel Edman expects to be used for SL.

I just didn't realize that because I have always exported sculpts as .png, not as .obj.

2)

If there is a default export resolution assignment for meshes, no one cares to discuss that.

If there isn't one, then manybe we're really talking about "LOD". Are we?

[Josh Susanto]

>here is a sphere with no symetry at all and no pucker. 

Perfect.

Thank you.

[Josh Susanto]

(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?)

>That depends on how you use your textures. If you don't use a repeat on your textures so every pixel will show on a non hidden surface, you have useless data. Other than that, yes.

In the tetra question, I haven't even been thinking about textures as being important. Thanks for mentioning that they might be. I actually thought I would at least start by making "blank", slightly shiny surfaces. 

(

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.)

>Difficult to answer, since a mathematical surface isn't neccecarily the same as a triangular polygon.

For a tetrahedron, why should it not be?

>I'll try to show the different possibilities for some shapes, including the tetrahedron and the box. I'll go with the shape resulting out of intersecting two identical objects, with the most visible unique surfaces as a result.

I appreciate that, but the most viable unique surfaces is not the only possible criterion. I'm personally more interested in the question of intersections which can be reasonably be described as "apparent vertices".

>First the number of unique mathematical surfaces for the two single objects against those on the two intersecting ones. Second the number of triangles needed in 3D modelling to make the original two shapes against the number that's needed to build the combined object without any hidden structure.

This is a good demonstration of very special sets of conditions. I think I should point out that most possible tangent uses of these solids don't fit the criteria applied in your examples.

>tetrahedron: 8 to 24 (1:3) and 8 to 24 (1:3)

>4 sides pyramid 10 to 32 (1:3.2) and 12 to 32 (1:2.67)

>5 sides pyramid 12 to 40 (1:3.3) and 16 to 40 (1:2.5)

>8 sided pyramid 18 and 64 (1:3.6) and 28 to 64 (1:2.3)

>cube 12 to 42 (1:3.5) and 24 to 51 (1:2.1)

>Let's not focus on the mathematical numbers, which are clearly in favour of anything besides the tetrahedron,  but on the 3D modelling ones on the right. As you can see the tetrahedron indeed has a better ratio than the cube, so one would guess that's the best option.

Moreover, the cube is only more greatly outperformed by 2 tetras, rather than one, and for less data, yet.

>However, on hard edges the vertices aren't shared between the different faces so we need to look at something else.

That's an important point of which I was unaware.

>Now look at the number of triangular faces the objects APPEAR to have. two tetrahedrons seem to have 24, two boxes seem to have 51, which is more than twice as many.

At more than twice the total data cost, yes.

>We already established a tetrahedron has 12 vertices according to SL (4 faces with 3 vertices each) when the edges are hard. This is exactly half of the 24 vertices for a cube (6 faces with 4 vertices each). I think math gives us a winner here and it's not the tetrahedron.

Given the criteria, I can't disagree with that.

>(I can't predict what will happen if we intersect 3 or more objects, but my intuition says the difference will get bigger with every object added. Please don't ask for the math on this, two was a pain already)

That's OK, thanks. Given your criteria, I would also expect such a compounding of the disparity as the number of parts increases.

>Hmm, forgot one thing, that is SL rendering cost is NOT the same as GPU rendering cost, which to my best knowledge is based on the number of normal triangles facing the screen. For a cube that is a minimum of two and a maximum of six. For the tetrahedron that is a minimum of one and a maximum of three. Again that exact factor two. Seems the way rendercost is calculated by SL isn't so dumb....

 So, again, I can get 2 tetras for the cost of a cube, even that way? 

Glad to hear it. Thanks.

I might add that there are fewer angles from which to avoid seeing a 3rd face of a cube than there are from which to avoid seeing the 3rd face of a tetrahedron, and seeing only one face of a terahedron should tend to be a pretty normal occurence, whereas seeing only one face of a cube would be quite rare. 

>I ran out of brain for today for this post....I'll answer the rest later.