Jump to content

[SOLVED] Mesh with multiple textures / UVmaps shows up (partly) black when imported into SL


Kiyoshi Nyoki
 Share

You are about to reply to a thread that has been inactive for 3871 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

Hello,

I have been trying my hand on a mesh building (just the outer shell) and I have assigned 8 different materials to the building (I did this in Blender 2.49). Then I upgraded to Blender 2.62, and added a UVmap, and a texture based on the UVmap, to each different material. To make the UVmaps, I dragged everything outside the 'work area' in the UV editor, and then manually selected and distributed the faces I needed on the UVmap. I used this UVmap, after baking the AO, as the basis for my textures.

The problem is that in Blender, after pressing F12, the whole building renders fine. When I import the mesh into SL though, some of the materials show as intended, others only show black. I have no clue what I am doing wrong, or why this is happening. Perhaps you have some ideas as to what is happening here.

Many thanks in advance,

Kiyo

Link to comment
Share on other sites

I'm not a Blender user, so I can't really help much in that regard... Your UV-mapping process sounds logical, especially since you say it renders fine within Blender. Mayhaps it's a quirk brought about by switching of Blender versions? ("Clutching at straws" guess there). Or mayhaps the problem materials aren't saved out properly for the export?

With your mesh rezzed INSIDE of SL... have you checked to see if all of the materials will accept random textures? (Your post doesn't mention if you have done this or not). To try and narrow down the problem, I would suggest just dragging any kind of texture onto each material face, just to see if the UV mapping is functioning for each. The black that you mention kind of sounds like either borked AO textures, or possibly non functioning UVs. (Generally, if you try to apply a texture to a non-UV mapped material/mesh, you will just get a flat colour (which I guess is an averaged colour for the entire image - I have seen anything from black to browns with my own failed meshes)).

If your material faces all show recognisable textures (dependent on where their UVs fall on the image), it could mean issues with the Blender baking. If you just get a big colour smear instead... that to me suggests problems with the UV-mapping process.

I hope this helps to at least error-trap the problem for you.

(Be sure to use the Aditi test grid for tweaking/testing/error trapping work - will save a lot on upload costs in the long run. You probably already know of the test grid, but I thought it prudent to mention it all the same).

(A Blender expert will no doubt jump in here to assist you further... Drongle, you there?) :matte-motes-wink:

:matte-motes-smile:

  • Like 1
Link to comment
Share on other sites

In regards to the Aditi test grid, as far as I know, you will probably need to redo your mesh quiz before you will be allowed to upload mesh there. It's not a problem though - just a quirk with how your account settings work on the separate grid or something.

The L$ balance you have there is purely for upload testing usage (figuring out costings etc) - it's definitely not transferrable to the main grid. However, it's excellent for helping you figure out relevant upload costs. If you run short of upload L$ on the test grid, a Linden employee will generally give you a quick top-up at no cost.

When you arrive on the Aditi Grid, just to a world search for "sandbox" to find a location to build in (the default landing point from memory is a non-sandbox area).

:matte-motes-smile:

Link to comment
Share on other sites

"Drongle, you there?"

Yes. I have been thinking what questions to ask. There are too many possibilities. I am not expert in Blender 2.6 ... hardly even used it, and I don't know what might be different. Kyoshi, Maeve's idea of applying a simple texture, may be a grid, is a good start. Your description of the mapping process is not entirely clear to me. But anyway, here are some questions that may or may not have anything to do with it...

1. Are you sure all (blender) faces were included in one, and only one, of the UV maps that were active when you baked? The AO bake background is usually black, so that any ambiguity and probably any missing faces could be black. Do any faces accidentally have zero dimensions in the UV map?

2. A trivial one - are you sure all the normals are pointing the right way?

3. Did you move any UV islands after baking them? That might move them into a black area.

4. Are you certain you applied the right textures to the right faces? And are you sure the texture repeats are 1.00, with no rotations or offsets?

Actually, if you have the model correctly textured in Blender and export it without changing anything, I guess only 2 and 4 are relevant, and 2 only if you have double-sidede rendering turned on in Blender, which would hide normal problems.

 For what it may be worth, here is roughly how I bake multiple materials (Gaia described a better method, without the need to separate vertices, but I have forgotten it for now). For each material, I use the material selection to select all the relevant faces and UV map them to fill the whole texture area. The maps for different materials can overlap, and that gives you the best texture resolution for a given texture size. Then, with the faces still selected, do Mesh->Vertices->Separate to make the material a new object, select that object, bake it and save the image. Then rejoin it to the main mesh, remove double vertices, and proceed to the next material.

 

Link to comment
Share on other sites

Heya Drongle, first off: thanks for your answer, it pointed me in a different direction to search for an answer. To answer your questions: 2, 3 and 4 are all okay, no problems there.


Drongle McMahon wrote:


1. Are you sure all (blender) faces were included in one, and only one, of the UV maps that were active when you baked? The AO bake background is usually black, so that any ambiguity and probably any missing faces could be black. Do any faces accidentally have zero dimensions in the UV map?

(My answers... I can't seem to get to make the quote option to work for me)

Well.... here it starts going wrong. I am not sure exactly what you mean here, but I do think you are on top of the problem. For each separate UVmap, I moved all the faces that I didn't need in that UVmap outside the black area (or outside the image), and scaled those faces to 0 (by using S -> 0) I could say those faces have zero dimensions. What I could try is to have all faces in one UVmap (the one for the first material) and then ONLY unwrap the faces I need for the other materials in separate UVmaps, instead of unwrapping all faces and scaling the faces I don't need to 0. I get the feeling somehow this is a texture conflict between several UVmaps... 

What I have found by trying to add different textures in SL, is that only the UVmap for the first material I created in Blender works correctly (i.e. is showing the right texture), all the ones I made afterwards show a brownish colour. That leads me to think that the UVmap for the first material somehow determines what the textures for the other materials need to be as well, instead of the other 7 UVmaps I made and assigned.

I am sorry if the description of the problem is unclear, but I do have tried to make it as clear as possible
:)

Kiyo

 

Link to comment
Share on other sites

That sounds like the problem. If you scale a face to zero in the UV editor, it will be all textured with a single pixel. It looks like that is the situation that pertained in your exported UV map. When you have parts of the UV map outside the area of the image, they behave essentially as if the texture is infinitely tiled. This can be very useful, to arrange repreats of thye texture without having to dissect and stack the UV islands, but in your case it would mean youir zero area faces end up at random places on the texture. I'm not sure why only the first material works, Perhaps you exported the collada file while just that one was non-zeroed. The Collada file will contain the UV coordinates that are there at the time you do the export. So if you had only one material correctly map at a time, then only one would have a proper UV map. You can easily make and arrange the UV maps separately for each material by selecting just the faces with each material. The problem arises with baking when the maps are on top of each other. I described my solution, but as I said, Gaia gave us a better one. I think it was something to do with hiding the other faces (at least from the render).

  • Like 1
Link to comment
Share on other sites

Thanks for your comment. I have been trying to wrap my mind around what you said, but I am afraid I can't get it to work yet. Are you saying that the total amount of faces in a mesh get to be split over all the 8 meshes (so a single face is never in 2 UVmaps at the same time) or are you saying that the faces of material A need to be inside the area of the UVmap image, and the other faces (for materials B, C, D, etc) can be placed as an island outside the area of the UV image for material A?

Ugh, this is all far more difficult than I ever imagined...

Kiyo

Link to comment
Share on other sites

I'm not on 2.6 yet, so I can't get specific either. But to answer this question, both. If you wanted all 8 materials(faces) to all be on one big texture, you want to unwrap All the poly on to one uv map. If you want 8 seperate textures on your inworld model, make a uv map per material.

Blender let's us have the best of both worlds. But this is where it gets confusing. So I'm going to paste a link to a Machinamatrix tute that shows how to use projection uv maps. I have a guess that this is where you are stuck too. Uv maps in blender have a few choices. Use them to render, or output. I figure you have one set wrong. Blind guess though.

 

http://blog.machinimatrix.org/3d-creation/video-tutorials/sculpties-older-tutorials-page/texturingsculpties_multiple_images/

The tute is about sculpties, where we had no control over the final UV. But it uses the same tricks, and explains the UV settings I think you are having an issue with.

 

Hope that helps!

  • Like 1
Link to comment
Share on other sites

Hello all,

Thanks for your efforts of helping me out xD It cost me all day, but I have tracked and solved the problem, thanks to the mentioning of hiding parts of the building. What I ended up doing was to hide all materials but one, then make a UVmap and AO-texture out of that, and then the same with the next texture, until I finished all eight. This means that each single face appears only once in 1 out of 8 UVmaps that I created, and together they form the complete UVmap for the whole mesh object. Now I have cracked this nut, I can start retexturing everything again xD

AO building_001.png

This is the building with the AO baked into 8 separate materials / textures, and me next to it on the test grid (thanks for that tip, I really didn't know you could test there!) xD Now that I have almost completed my first ever project in Blender, I can hardly wait to start on the next one xD

Thanks again!

Kiyo

Link to comment
Share on other sites

Wow Kiyo, that's turned out really nice! :matte-motes-smile:

Getting a bit off topic: Looking at its geometry, I'm wondering what kind of Land Impact cost it has. Is it pretty high? Reason I ask is due to the combination of its size AND the amount of complicated geometry (triangle count) I think I can see there. (Mostly the rounded columns on the bottom floor, the curvey / rounded shapes in the decorative pieces, and the windows in the roof area (the ones with the rounded tops and three-step insets).

Something worth considering, to bring down the Land Impact cost (assuming it is pretty high), is to reduce the geometry to relatively simple shapes where the triangle counts are expensive - and use your baked texture as shown here to "fill in" the missing geometry detailing. It's a balancing act, of course, between visual look and Land Impact cost, but definitely worth exploring.

Still, that's a damned fine piece of modeling work there Kiyo! :matte-motes-smile:

Link to comment
Share on other sites

Thank you :) The land impact cost isn't as bad as I expected, to be honest. It is going to replace a 210 prim building, that is the maximum amount of prims I am allowed to use. The way the building stands now (25*25*20), and without specifying the LOD-models for the lower LOD-levels, it comes in at about 130 prims. Because the building is so big, it renders detailed from a huge distance already, so I plan to make the three remaining LOD levels really low poly count, with a picture of the detailed building slapped on to it. I expect to end up somewhere around 180 - 190 PE.

But essentially you are right, ofcourse. There is a fine balance between too much and too little detail, and because this is my first attempt, I decided to go all out :) And I am pretty surprised that the land impact isn't much higher (obviously it would be if I let the upload interface determine the lower LOD-level models!).

Once again, thanks for your nice words AND your helpful advice! :)

Kiyo

Link to comment
Share on other sites


Drongle McMahon wrote:

That is well above the 10.86m size above which the low and lowest LODs have no effect on the LI. So you should concentrate on simplifying the medium LOD and use that for low and lowest as well.

Having no effect on the landimpact doesn't mean it has no impact on a graphics card I would think. I do agree it's wise to concentrate on LoD medium in this case, but using that model for the lower two sounds like a really bad idea. (That is unless the lower LoDs will never show, which I doubt, but am not sure of)

 

@ OP ..nice build indeed.

Link to comment
Share on other sites

"unless the lower LoDs will never show"

Well, I think the low would show if you had renderVolumeLODFactor (rvlf)= 1.125 (low graphics default) and draw distance set to 360m or more. That's a rather unlikely combination. At rvlf= 2 (high graphics default) it wouldn't show unless you had dd set to more than 640m. In my official viewer it can't be set higher than 512*. I don't know about tpvs.

It sort of depends on how far the medium is reduced. I was meaning to imply that that is where the proposed simple box should be used, as was the plan. In that case, that would already be so simple that it doesn't matter using it for the lower LODs which will only be seen in quite excetional circumstances. If the simplification at medium is less extreme, then you may be right. In that case, you can take the precaution of using one triangle per material will do, as it will almost generally be seen. If the box is 10 triangles (no bottom needed, it hardly seems worth it.

ETA: the LOD switches are about rvlf * radius / f where f is 0.24 (high->medium), 0.06 (medium->low), 0.03 (low->lowest). That means roughly 4x, 16x and 32x the radius, then multiply by rvlf. There are some other adjustments in the code, which I have not fully understood, but I think they make the distances a bit further, not nearer. I could be wrong.

*Actually, the 512 limit is only in the preferences dialog. There is a debug setting renderFarClip which sets this and may allow it to be much higher. So that's another reason for being more careful, I guess.

  • Like 1
Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 3871 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...