First Mesh, couldn't dae/partly invisible/how do seams work?

[October Ronas]

Blender v2.76 // SL Firestorm 4.7.5

Q1 ) Couldn't dae?

I'm just now learning how to mesh for SL. I used a base plane and extruded to make a letter shaped mesh. I marked seams and made the UV but then when I went to upload it into SL I got a message saying I had a dae parsing issue and should view the log. I have no idea how to view the log but I did research here. I used a suggested method and saved it as an obj, re-imported the obj and saved as dae. That worked but...

Q2) Parlty Invisible?

The top and bottom of the letter appear from all angles but the sides are invisible and can only been seen on the inside. I know on other posts people post screenshots of their settings but I don't know which settings to take a picture of. I will say that I had done research prior to making the mesh and had put my settings according to a post about what SL requires.

Q3) How do seams work?

I noticed after saving my mesh as an object I lost my market seams. I also saved it as a ply once and had the same results as the obj. That time I took the time to re-seam my whole mesh but when I imported it to SL I lost my seams again? I don't understand, seams are supposed to be considered 'faces' inside of SL right?

 

I'm a long time builder so I know my way around all the related softwares but not experienced with blender. I'll gladly post any screencaps that might help me resolve all of this if someone can tell me what I should get a picture of.

[ChinRey]

---

October Ronas wrote:

Blender v2.76 // SL Firestorm 4.7.5

---

If you use Firestorm to upload, make sure it's the 32 bit, not the 64 bit version, and the Second Life-only one, not the one with access to other grids too. The reason is that Second Life uses the HAVOK physics engine. HAVOK only exists in a 32 bit version  and Linden Lab's user license only applies to Second Life so they're not allowed to make it available to other grids. (The latter is a bit silly since it's easy to reconfigure any viewer, even the official SL viewer, to work on any grid and the client side part of HAVOK probably wouldn't have had any effect on a non-HAVOK sim anyway.)

---

October Ronas wrote:

I have no idea how to view the log but I did research here.

---

It wouldn't have done you much good anyway. There may still be somebody at LInden Lab who are still able to decipher that log...

---

October Ronas wrote:

The top and bottom of the letter appear from all angles but the sides are invisible and can only been seen on the inside.

---

Normals pointing the wrong way. Common Blender problem, not only for SL. Select the problem faces type ctrl-F and select "Flip Normals".

---

October Ronas wrote:

I noticed after saving my mesh as an object I lost my market seams. I also saved it as a ply once and had the same results as the obj. That time I took the time to re-seam my whole mesh but when I imported it to SL I lost my seams again?

---

As far as I know, the seams are only used for UV mapping. They may have other purposes too but they're of no use whatsoever inside Second Life.

---

October Ronas wrote:

I don't understand, seams are supposed to be considered 'faces' inside of SL right?

---

No. Materials in Blender are Faces in SL.

[October Ronas]

Thank you sooo much! That was a very very helpful response. I'll go do the research on the things you mentioned and remember to flip the normals and put material on my mesh before I try uploading it again. ^^

[Drongle McMahon]

A bit more ...

Seams have no existence outside of Blender, either in obj or dae files, because they are only instructions to the UV unwrapping function in Blender. Once the UV map is generated, what is marked as a seam has no further effect. So it isn't included in the exported files, which have no means of carrying that information anyway. That's why they aren't there in the re-imported model from obj file.

The reason you don't see the effects of inverted normals, by default, in Blender is that the 3D view uses two-sided rendering - both sides of any polygon are shaded. In SL, only one side (the one with the normal sticking out of it) is rendered. So if the normal is inverted, you see only the back surface, which should be invisible. You can preview this behaviour in Blender by turning on "Backface culling", using the checkbox in the "Shading" section of the Properties panel, usually to the right of the 3D view. That way you can save the effort of uploading to identify the inverted normal problem. To see the (face) normals, click the rightmost of the three box icons in the "Mesh Display" section of the Properties panel in Edit mode.

Pulling an extruded face in the direction opposite to its normals is one way you can get inverted normals.

 

 

[ChinRey]

---

Drongle McMahon wrote:

You can preview this behaviour in Blender by turning on "Backface culling", using the checkbox in the "Shading" section of the Properties panel, usually to the right of the 3D view. That way you can save the effort of uploading to identify the inverted normal problem. To see the (face) normals, click the rightmost of the three box icons in the "Mesh Display" section of the Properties panel in Edit mode.

---

A third way to identify normal issues is to jsimply look at the color of the polys. Backfaces are shaded according to the light they get from the other side and on a larger surface with mixed normals they will always stand out because of that.

We should also have mentioned there are two quick ways to make a large number of normals conststent in Blender: Ctrl-N to make all nomrals in the selection point outwards, Cltr-Shift-N to make them all point inwards, regardless of which way they flipped at the start. Of course on a complex model it is not always possible for Blender to determine what is in and what is out but they work surprisingly well and can save you a lot of time hunting for the misbehaving polys.

(Edit - and completely off topic: Am I the only one who can't help thinking how many polys we could have saved if SL had allowed for backfaces?)

[Drongle McMahon]

"Am I the only one who can't help thinking how many polys we could have saved if SL had allowed for backfaces?"

It might have saved a few*, but then it would have meant either nearly twice as many triangles to render (or twice as much calculation of occlusion to know what not to render). I think the consequent cost in lag would have been much higher than any benefit from avoiding mistakes (covering up laziness ?). In Blender it's fine to see the backfaces because it mnakes it easier to select, but in a real-time environment, I don't think it would be a good idea.

*Not many - unless you want the same texture inside as outside, you'd have to make them a different material anyway, and the triangle count would go back up. If you don't get to see the inside, then you don't need the triangles anyway.

ETA - actually. considering a bit more carefully, that is probably an exaggeration. Since any triangle can only be seen from one side, the renedring would only have to work out which side for each. That's still a pretty heavy burden though.

[ChinRey]

---

Drongle McMahon wrote:

ETA - actually. considering a bit more carefully, that is probably an exaggeration. Since any triangle can only be seen from one side, the renedring would only have to work out which side for each.

---

Yes, that was my point. Also, from what I understand (I may be wrong) vertices add a lot more to the load than polys.

---

Drongle McMahon wrote:

That's still a pretty heavy burden though.

---

You'd gain some and loose some and I have no idea if the sum would be positive or negative. It's all just idle thoughts anyway.