Gaia Clary

[edit]: I just found an easier method (i still use the kettle as example) 3D view: go to face select mode select all faces UV editor: Create a new image "interior-texture" (or select it if it already exists) Deselect the interior faces in the UV editor (keep all others selected) Create another image "outside-texture" (or select it if it already exists) Bake

Vivienne Daguerre wrote: I would like to see some detail about how you took the kettle interior UVs and put them onto their own UV map. I am guessing that you are probably one step ahead of me and already plan to do this. I want the kettle quest to be fully independent from any 3D editor. So neither the text document nor the planned video "making of the Kettle" will explicitly show how exactly some things are done. However i plan to also make a few detailed blender specific "Howto" videos and one of them will definitively be "Making of the UV-map" Actually that part is realy easy: Afer i have marked the seams, iselect all verts and then press "u" (in edit mode) and then i choose "Unwrap". that already does most of the task. Then i only select the parts, scale them and move them on the map. Ok it is a bit tricky to separate the map for the interior into another image...

Here is an attempt for a simple explanation and after writing it i think some informal images would help a lot ;-) Each vertex contains actually 3 values: The vertex position A vertex normal A UVmap position In principle this information has to be maintained for each triangle corner inependent on whether the vertex is reused in multiple triangles or not. this is so because the vertex can be located at different postions on the UV map for different triangles. Also the vertex nromal depends strongly on how the associated triangle is placed in 3D space. But sometimes a shared vertex can use the same UV coordinates AND the same vertex normal. in such cases (and only then!) a vertex description can be shared among multiple triangles. This happens especially in 2 cases: If multiple faces with shared vertices lay exactly in the same plane, then the vertex normals are all identical. If smoooth shading is enabled, then all vertex normals point into the same direction inependent on how the associated triangles are placed. One extreme example is a simple cube. In that case we have 12 triangles (2 per side) and that makes up for 36 vertex descriptors. But on each corner we find only 3 different vertex normals (because the faces are positioned in xy-plane, xz-plane and yz-plane and so each vertex normal can only have one of 3 values). Hence we find 8 corners with 3 vertex normals each. That sums up to 3*8 = 24 vertex normals. Consequently the list of vertices can be reduced by eliminating the dupliate descriptors and we end up with only 24 descriptors instead of 36. If we enable smooth shading, then the vertex normals of all vertices on a corner point into the same direction. So we end up with exactly 8 face normals and this we will also see only 8 vertex descriptors.

I like that version. It gives more detailed information about the vertices and their relations to triangles and answers one more question (max. verts per mesh) some more remarks: From the discussion in the other thread we learn that one vertex is potentially counted multiple times. From the schema you provide, it looks more like each vertex is counted once independent from its reusage in multiple faces. And also the dependency of vertex count from the UV map is not adressed here i guess ? [edit]: i think i understand now: A vertex is reused only if position, vertex normal AND UV position match. So your map now indeed answers all questions (sort of...)

may i propose a small change ? I think a triangle has always exactly 3 vertices ?

probably so, yes. But remember that the intention of that build was to show what happens with big meshes compared to link sets made of small meshes...

My example above (16 spheres in one mesh) uses 16 submeshes, but it imports as one single mesh. So i am afraid that you must separate submeshes into objects and upload them all. Fortunately you can upload them all in one upload. Then they will be bundled together as a linkset.

Dain Shan wrote:Ok I will try to load and export it from Blender 2.49b .. only .. can someone point e to an phyton install ( an executable ) that will work? I tried to install the newest but it seems that diddnt work. Blender 2.49 still tells me that it need the Phyton scripts and i cant find an executable for an older version ( so 2.6 of Phyton ). A pointer would be really nice Thanks in advance I could not find a binary python release for python-2.6.7, only a source release. But a realy easy way to get a full functioning blender-2.49b for windows or Mac with the correct python release and even a slightly enhanced Collada exporter is Jass-pub. That is an all in one binary package. It comes with an installer and installs a functioning blender with no need of any additional software (Primstar-1.1 for Sculpty making is included). See here for details: http://blog.machinimatrix.org/jass/ And from here you can get a realy enhanced Collada-exporter for Blender-2.49b: http://blog.machinimatrix.org/spikes-after-mesh-upload-to-sl/

Thank you Drongle. So every day i learn a bit more ;-) My previous example was made without a UV map... With UV map i get 17 vertices for the sharp edge case and 27 vertices for the smooth edge case... I am no longer sure that i still want to explain the behaviour of meshes in detail. So when we are through this mesh thing, will we then all get a diploma from LL ? For practical usage of Math in 3D ? I wonder if it would make sense (and help) to see the number of materials in the uploader and maybe some infos regarding the UV map...

I tried it with a Collada export from Blender 2.49b and now everythiong makes sense to me again. And here is the difference between a smooth and non smooth cube as i see it: These numbers make a lot of sense to me: for the smooth cube(left side): Each vertex is counted exactly once, so we see 11 vertices as expected. For the sharp edged cube (right side): Each vertex is counted once for each different face normal. You can see how the numbers count up from the following image: Each corner is connected to faces with 3 different face normals. So each corners counts up to 3. The vertices inside the bottom plane of the cube are each counted once because all attached faces have the same face normal. Hence we get: 8*3 for the corners 3*1 for the verts in the bottom plane sum: 27 verts So it looks all correctly handled from the Mesh Importer. Are you sure that you have removed duplicate vertices in your cube ?

Blender 2.5 uses Collada 1.4.1 The vertex duplication in principle comes from the fact that when you use sharp edges then the vertex normals take effect. I am still not 100% sure about the exact number which you see. it may indeed be an effect of Collada-1.4.1 (which to my understanding is not (fully?) supported by LL) ... You can try this: in Blender go to object mode, then smooth the cube. Alternatively set the crease angle to 90 degrees in the mesh-importer. In both cases you get the expected number of vertices. Explanation (sort of, please can someone who knows better can give a more precise explanation ?): You can decide for each face if it shall be lighted with smooth transition to adjacent faces or with a sharp visible angle. When you make the entire object smooth, then you have only smooth transitions. In that case only the face normals are taken into account, so you get exactly the number of vertices that you expect. When you add sharp transitions, then suddenly the angle between the edges of 2 faces plays a role. Since this angle can change along each edge, now the vertex normals play a role, and this means each vertex has to be counted multiple times depending on how often it is reused in different faces. So each reuse of a vertex is counted probably because the vertex normal information must be stored somewhere. So in principle you have 3 vertices per triangle to count and you would end up in 3*18 = 54 verts. It appears to me that the vertices in the flat plane at the bottom of your cube do not get counted because some of the vertex normals of the shared vertices point into the same direction... As i said, i am far from sure if my explanation is correct. At least some details are missing, so i wuold be very interested to learn what is going on here in detail.

It depends on the size of the objects. The resource costs vary extremely depending on which LODS are available. If the mesh gets bigger, then fewer LOD levels will be displayed and hence the total mesh costs explode. As Drongle mentions you can get past this problem by splitting larger meshes into smaller parts. Here is an example: On the right side of the image you see 2 big crosses made out of spheres (7.5 meters wide and high). The right cross is actually a linkset containing 16 meshes of individual spheres. The other one is one single mesh. The resource costs of the single mesh exploded to 67.6, while the linkset keeps down at 13.2 Now look at the left side of the image. There i have the same 2 crosses scaled down to a size of 1 meter in width and height. Now the resource costs for the link set are higher (12.1) while the single mesh only costs 6.6 Inbetween the 2 extremes i have also added 2 crosses with width and height scaled to 2.5 meters. And already there the link set wins (12.2 compared to 27.4 for the single mesh) So for small objects it makes sense to put all pieces into one mesh. For larger objects it makes sense to split them into smaller objects. I can see exactly the same behaviour with the kettle. Its costs depend on whether i place the handle straight upwards (which makes the object bigger) or let the handle fall aside. So it may be cheaper to split the object into kettle and handle and link them together in world, but i have no reliable numbers yet for this, so i will post that later.

So it makes much sense to optimize also LOD3 when you plan to make big objects... Drongle, is it that what you mean ?

Something to think about... Here are some primstars: All stars have the same size <1.0, 1.0, 0.125> only their distance from the camera is different. One of them is A sculpted Prim. The image is made with renderVolumeLODFactor=1.125 Now think of this: Take a mesh, make a full Blown LOD3 model (i used 1024 faces just to show you...)Minimize LOD0,1,2 to the smallest possible blob you can get (1 triangle maybe).Then set RenderVolumeLODFactor to 4And see this: Note, the "smaller" stars (all again same size <1.0, 1.0, 0.125>, but different distance) are not rendered as blobs but as full blown objects. It is only the image resolution of the picture, which makes them look like Blobs. So if you can live with an Object which collapses to nothing on LOD2 (like you see with so many tortured Sculpted Prims) then you can get very cheap meshes. With easy words: If you need LOD, the resource cost raises up. If you want to go with renderVolumeLODFactor, the resource cost goes down. Now i only wonder what LL has in mind. Do you want to reduce the streaming costs on your servers or do you want to reduce the load on the client viewers ?

Drongle McMahon wrote: 48 segments around is a lot. Do you think that's the minimum? If you made the soup a separate object, then you could have a whole set, with bones sticking out of them, or peas, or .... I wanted to have the edge as smooth as possible. With 48 edges it remains round even when you go very close. So yes, maybe 48 is too much here. I might try it with only 32 edges. that may be good enough for the LOD3. ALthough it appears to me as if that will not do much on the render costs. What realy matters is the LOD4 shape. When you do an extreme reduction here, it gets significantly cheaper. Ill try with a 6 sided cylinder and see if that makes a big difference in the price. Regarding the interior of the kettle: Yes, making it a separate object would give it more spice ;-) But i have another plan here which will not only add spice, but also dynamic ;-) So the kettle quest is not over yet...

After doing a lot of experimentation and starting over and over agina, i finally think that i found a way to get away with cost effective meshes for rounded objects. Here my very first kettle below 2 prims: I wanted the handle to keep as smooth as possible because for me it looked like having too few precision on it disturbs me most. I could get the whole kettle down under 2.0 (size 0.5 meter in diameter) by using a very very very reduced LOD0 (see on the right side) Now i will add more edge loops to the higher LODs and try to keep the whole thing below 2.0 [edit]: Well, render cost is now 2.0: Here is the mesh (864 faces): I needed to reduce the faces as much as possible while keeping the overall shape as constant as possible. This i could only manage by introducing triangles. Any attempt to keep with Quads could not get me down to 2.0 while keeping the smooth roundings intact. And the UV-map: I have created a separate UV map for the inner part of the kettle (not shown here). The realy cool thing about that is that i can place any flat image into the green area (placeholder for "soup" ;-) ) so i just can go out and find whatever ingredients i wish to see there. And they all will fit. I even can use a 1024*1024 texture there if i wanted to do that (but which i do NOT want to do). I guess i can reduce the facecount on the handle a bit too and spend a few more faces on the kettle shape... As a sidenote: I think that when i do this same object as Sculpted prim then i will start getting issues at least on LOD0 and LOD1. LOD2 might work or not.

Blender 2.5 will suport Collada 1.4.1. (see https://jira.secondlife.com/browse/CTS-638 )

Hi. I was looking at the change logs of the viewer builds to understand if a particular issue has been solved. But i do not know how to match the used ticket numbers on the viewer build reports to the ticket numbers used in the CTS project. Is there a guideline, or where can i see those internal tickets ( e.g. SH-1796 ) ? Sometimes i see no ticket numbers at all but "trivial" in the report like in build 232749 . What does that mean ?

Maybe the servers get restarted frequently these days ...

Nyx Linden wrote: We should already be saving your import settings to a file next to the collada file you're importing with. When you re-select a previously uploaded collada file, the importer should load those settings. If this is not the case, that's a bug we should fix Good to know, but... Although the lod shapes are preserved in the slm file, the sources are not preserved. The information from which files they have been made originally is lost in that file. Why did you choose to make it a binary file ? Wouldn't it be much more helpfull to be able to export such files from our local 3D Editor ? in XML for example as i propose in the feature request ? That would allow us to create helper tools (without need to create a special TPV ...) 

Hi. This morning after countless re-uploads and tests i finally got annoyed about remembering the exact set of files and attribute settings for my mesh uploads. it sometimes takes me minutes to specify and check the import settings. And all so often did i upload a rigged mesh and forgot to check the "skin weights" in the modifier tab ;-( So i added a feature request for getting an import description file: https://jira.secondlife.com/browse/CTS-634 I think that such an addition could become "the builder's friend" and i am certain that we will find a way to create such a description file by script and add that as another export option to our favorite 3D editor ... hint,hint, ... ;-) If you like this, please vote for it on the jira (although i am not sure if voting is necessary)

All texture features work for me (shiny included). I even can change them now while wearing the mesh. I use viewer Second Life 2.7.3 (232686) Jun 11 2011 15:48:29 (Project Viewer - Mesh) on windows 7

I updated the table.

While experimenting a bit further i came across this issue: Both kettles are mesh objects. Both kettles have exact the same appearance, the same LOD decimation, everything is equal, exept : I joined the 2 objects into one mesh object (i did that for each LOD separately) i simplified the physics mesh Here is the result: Kettle optimized (left side) original (right side) type mesh mesh objects 1 2 faces 1280 1024+256 Physical objects 1 2 faces of phys. obj. 16 45 complex hulls 1 2 size 0.49,0.47,0.32 0.46,0.46,0.31 (kettle) 0.48,0.25,0.16 (handle) Prim Cost 5 3 Streaming cost 7.2 3.2 + 4.4 upload cost 100L$ 110L$ Maybe that needs either a fix or another explanation. I am also not at all sure about what "upload cost" means here (Develop->Show Info -> Show Upload Cost). This probably is also not fixed yet ?

smaller and larger regarding the number of triangles per mesh. I just corrected this in my previous post ;-)