Jake Koronikov

Zbrush's ZRemesher is extremely powerful tool, but unfortunately it does not preserve UV layout. According to my knowledge there is no tool for auto retopo that would keep the UV's ...and...there propably there will never be such a tool. Spiral edge flows are very typical when using ZRemesher. My opinion is that "ZRemesh Guides" brush is not so easy to use, especially when you need to adjust the curve around cylinderic shape. Easyer brush is "CreaseCurve". After CreaserCurve operation you can use ZRemeshGuides and give FrameMesh command with creased edges. CreaseCurve is much more easy to use and it cuts tru the mesh, so you do not need to play with circular guide curve. Several loops created with CreaseCurve (or zRemeshGuides) will prevent spiral edgeflow and everything is beautiful:) ETA: This workflow is presented very cleary in ZClassroom (Joseph Drust, one of the greatest ZB lesson makers ever!). If you are familiar with zremesher you can go directly to about 14:00 mintes to see the workflow. http://pixologic.com/zclassroom/homeroom/lesson/topology/ (video name Zremesher on the page)

Maybe the RenderMan texture (and various map) baking capabilities could be used when designing for SL. But, not commercially....

The log file is actually the one you mentioned before: /users/xxxx/appdata/roaming/firestorm_x64/logs/fir estorm.log. However, it is not very easy to read. If you shut down the viewer after the upload error, you might find the corresponding log file lines when scrolling from the end of file some pages upwards. You should propably use search words like "upload model", "asset", "collada importer" or something like that. The viewer gives this "see the log file for details" in those situations when there would be more than one error message appearing on the screen. So..multiple errors in dae file. ETA: This is about what the log file section looks like: "2014-05-29T07:56:08Z INFO: llui/llfloater.cpp(668) : LLFloater::openFloater: Opening floater Model Preview full path: /main_view/menu_stack/world_panel/Floater View/Model Preview 2014-05-29T07:56:08Z INFO: newview/llfloatermodeluploadbase.cpp(47) : LLFloaterModelUploadBase::requestAgentUploadPermissions: class LLFloaterModelPreview::requestAgentUploadPermissions() requesting for upload model permissions from: https://sim7030.aditi.lindenlab.com:12043/cap/e677fc83-b0f6-1a60-1aa6-eec3644c09b9 2014-05-29T07:56:08Z INFO: newview/llfloatermodelpreview.cpp(1599) : LLModelLoader::doLoadModel: Collada Importer Version: 1.4.1 2014-05-29T07:56:08Z INFO: newview/llfloatermodelpreview.cpp(1609) : LLModelLoader::doLoadModel: Dae version 1.4.1 2014-05-29T07:56:12Z INFO: newview/llviewerdisplay.cpp(232) : display_stats: FPS: 45.50 2014-05-29T07:56:22Z INFO: newview/llviewerdisplay.cpp(232) : display_stats: FPS: 54.90 2014-05-29T07:56:32Z INFO: llmessage/llcircuit.cpp(1211) : LLCircuitData::dumpResendCountAndReset: Circuit: 216.82.40.147:12035 resent 49 packets 2014-05-29T07:56:32Z INFO: newview/llviewerdisplay.cpp(232) : display_stats: FPS: 33.70 2014-05-29T07:56:42Z INFO: newview/llviewerdisplay.cpp(232) : display_stats: FPS: 24.70 2014-05-29T07:56:52Z INFO: newview/llviewerdisplay.cpp(232) : display_stats: FPS: 24.50 2014-05-29T07:57:02Z INFO: newview/llviewerdisplay.cpp(232) : display_stats: FPS: 24.70 2014-05-29T07:57:13Z INFO: newview/llviewerdisplay.cpp(232) : display_stats: FPS: 24.70 2014-05-29T07:57:23Z INFO: newview/llviewerdisplay.cpp(232) : display_stats: FPS: 24.50 2014-05-29T07:57:33Z INFO: newview/llviewerdisplay.cpp(232) : display_stats: FPS: 35.20 2014-05-29T07:57:36Z INFO: llui/llfloater.cpp(668) : LLFloater::openFloater: Opening floater Model Preview full path: /main_view/menu_stack/world_panel/Floater View/Model Preview 2014-05-29T07:57:36Z INFO: newview/llfloatermodeluploadbase.cpp(47) : LLFloaterModelUploadBase::requestAgentUploadPermissions: class LLFloaterModelPreview::requestAgentUploadPermissions() requesting for upload model permissions from: https://sim7030.aditi.lindenlab.com:12043/cap/e677fc83-b0f6-1a60-1aa6-eec3644c09b9 2014-05-29T07:57:36Z INFO: newview/llfloatermodelpreview.cpp(1599) : LLModelLoader::doLoadModel: Collada Importer Version: 1.4.1 2014-05-29T07:57:36Z INFO: newview/llfloatermodelpreview.cpp(1609) : LLModelLoader::doLoadModel: Dae version 1.4.1 2014-05-29T07:57:36Z INFO: llprimitive/llmodel.cpp(2170) : LLModel::matchMaterialOrder: Material of model is not a subset of reference. 2014-05-29T07:57:36Z INFO: llprimitive/llmodel.cpp(2170) : LLModel::matchMaterialOrder: Material of model is not a subset of reference. 2014-05-29T07:57:36Z INFO: llprimitive/llmodel.cpp(2170) : LLModel::matchMaterialOrder: Material of model is not a subset of reference. 2014-05-29T07:57:36Z INFO: llprimitive/llmodel.cpp(2170) : LLModel::matchMaterialOrder: Material of model is not a subset of reference."

The lowest LOD level has very strong effect on LI. Your example is very lowpoly, whitch is very good. But the LOD0 triangle count is still 84, whitch is quite a lot in SL (would not be lot somewhere else maybe). I do not know the exact formula, but maybe you should try to lower the lowest polycount to something like ...20..30. It should bring the LI down even more.

At least in about version 2.6 (or later) Blender this can be avoided if you keep the uv-map names same in both objects. So, for example, if both objects have only one uv-map and you name both of them as "UVMap" -> should solve the problem.

Oh, true, Gaia. 3ds Max method..."procedural mapping applies planar maps based on different vector-projection methods to texture polygons..." ...umh...:matte-motes-zipped: *tries to think very hard and understand what I read*.....*this time better just give up thinking*...*a little head ache*...yeah..Someone more wise than me could maybe help the OP.

Just got a bit curious. In whitch 3d program there is a unfolding of unwrapping option "Unfold Normal" ?... Maybe someone can help you after we get the idea of software that you are using. There is a huge amount of different kinds of unfolding/unwrapping types and tools around. The unwrapping/unfolding itself depends on the model you are working with. There is no general rule about how to unwrap. Well..some simple rules tho: If you are modelling a planet -> Spherical would be good starting point If you are modelling a submarine -> Cylinderical would be good starting point If you are modelling a simple house -> Projection unfolding on each wall would be maybe good If you a modelling a flying dragon with armors -> maybe schedule at least 6 hours for perfect unfolding

When a derivative work created from the original is considered to be "new work"? The question seems to be complex, there is no simple answer. US Copyright Office has given some considerations about this: "A typical example of a derivative work received for registration in the Copyright Office is one that is primarily a new work but incorporates some previously published material. This previously published material makes the work a derivative work under the copyright law. To be copyrightable, a derivative work must be different enough from the original to be regarded as a "new work" or must contain a substantial amount of new material. Making minor changes or additions of little substance to a preexisting work will not qualify the work as a new version for copyright purposes. The new material must be original and copyrightable in itself. Titles, short phrases, and format, for example, are not copyrightable." There is no exact definition for the border line when a new work is not anymore considered as original. There is also other aspects. SL is definetely not only playground for US residents. In a case where (for example) Chinise resident uses Brazilian resident's copyrighted material that is located in a server based in US. Definetely a law case that no-one would like to get involved in. No matter on whitch side you are, you probably loose. I tried to figure out in my mind a non-SL situation where this kind of dae-file licence issue would be possible. DAZ3D is a company where same kind of issues may arise. Their commercial 3D models can be used in a such way that the customer sells the model in competition with DAZ3D itself. The reason is about same as in SL - a closed community and closed software solutions for models. Closed markets. I found their official forum post regarding this. And they propably have encountered exactly same huge difficulties in defining when a model is derivative and when not. Here is the post: https://helpdaz.zendesk.com/entries/123984-DAZ-3D-s-stance-on-distributing-derivative-models I can read between the lines that DAZ3D lawyers have not been able to give any exact answers

Hey again! Sorry If I am being so boring math-scientific in this specular issue, that is just the way I try to solve problems... Personally I do not know much about math behind the specular calculations, but I tried to simplify the problem we are talking here. Maybe there is someone who could explain us what is happening here when specular glossiness is low (about below 50 as you both mentioned). ? As far as I understand, the final color is achieved by adding specular map value to the diffuse map value. I think after diffuse color is tinted with scene lights. So if diffuse color is red <1.0, 0.0, 0.0> and specular map gives gray <0.5, 0.5, 0.5>, the result is pink kind of color <1.0, 0.5, 0.5> Tho, I am not sure how the glossiness parameter affects this, because inworld a high glossiness will turn the result strongly towards white (or the light bulb color to be exact). Then there is also specular color tint in SL specular settings. I guess this is multiplied with the specular. Tho I have no idea is it multiplied with specular texture or with the final effect... I made some extremely simplified tests inworld with a sphere that has also a simple normal map. What I do not understand is that when specular glossiness is low, the default sunlight and a white local light give quite different result. I took a default SL lightning as a test environment, because I think majority of customers are using that. When dealing with clothes, there is not much to do when trying to make things look good in every possible windlight setting. People wear their clothes just in any environment. But I think the problem that should be solved is the very strong local light effect on low glossiness specular - as mentioned earlier. So, first image is a setup with diffuse red <1.0, 0.0, 0.0>, glossiness 15, pure white specular map. As a calculation red+white is white <1.0, 1.0, 1.0>. I understood that both local and sunlight should give same white specular. But they do not. Only local light gives the white specular. This is what I have been thinking practically as "sunlight does not have enough power on specular effect due to its directionality". Also mentioned this in earlier post. In the second image specular is changed to exactly same color as diffuse. So the specular should be red, red+red is still red <1.0, 0.0, 0.0>. Now both sun and local light look same. In the third image, specular is pink <1.0, 0.5, 0.5>. So specular reflection should be red+pink, that is still pink <1.0, 0.5, 0,5>. Well, local light gives pink specular, but sun light still stubbornly stays red. Finally I added environment reflection, whitch I have been using in some metallic objects. This gives more bright specular in sunlight, whitch cannot be achieved using only glossiness. Well, this requires some spec map alpha channel tweaks to make it look good. But this last image is about what I would expect the first image would look like. So..umh..yeah. Is it possible the sun color has something to do with this, or maybe the ambient color? Sun color is more like very dark blue if I check it from the environmental editor.

This is kind of a painful issue in SL, I have encountered exaclty the same. According to my understanding this is related to "power" of sunlight compared to local light in SL shader. The default sunlight is a directional light that emits rays only in one direction. Local lights are more like point lights and those emit rays in various angles. Well, of course SL does not have any raytraced real time shading. What this all causes is that default sunlight does not give enough specular effect. And local light gives too much specular compared to sunlight. However, both give reasonably good amount of diffuse ...and that is what makes it so hard. The diffuse channel looks about same in local and sun light, but specular goes it's own way. One somewhat easy way to get arount this is to use environmental reflection. But to avoid wet or too metallic look, the normal map specular map alpha channel should maybe have black-and-white version of the diffuse texture tweaked with curves or brightness. At least with metals this method helps to get more specular in sunlight. Cloth fabrics are not so easy....

If your licence says: 1.You may not re-sell or give away the mesh templates with full permissions. 2.You may not re-sell or give away the work resulted from the mesh templates with full permissions. ==> You can sell the resulted work in any other form but absolutely not as copy/mod/trans (full perm). This means you can modify and texture it and sell it for example as copy/mod/no-trans, copy/no-mod/trans, no-copy/mod/trans and so on. As long as one permission parameter is "no". Rigged mesh clothes are usually sold as copy/no-mod/no-trans. I would guess that most of those full perm .dae files are also not allowed to be sold as copy/trans. But that should be found in the licence.

Hieronimos Audeburgh wrote: Thanks for all your replies... I'll keep you posted, lol : P : ) DerpWolf: when you were setting the parent for your cylinder (control+P), what type of parenting did you use? I would propably go so that I would export the shape I use inworld. Then I would import that shape .xml to Avastar. Then I would design the roundiness according to the real body shape that will be used. After this kind of a workflow the final mesh will look exaclty same in blender and inworld. And this is due to the fact that vertices weighted to mShoulder bone are affected by avatar shapes sliders inworld. Gawd only knows how much the influence is..but there definetely is influence

One more trial to solve this: If I understood right, you have rigged this to mShoulder. So, it is not fitted mesh...but the avatar shape slider "Body thikness" inworld affects somewhat the mesh shape on that area even without volume bones. Maybe try to play with your avatar "Body Thikness", "Shoulder width", "Torso lenght", "Body lenght" and so on sliders inword - after you wear the mesh. Or change your shape to default male avatar inworld. I would predict that you will see some change from oval to round

They may be double safe. Hehe, I agree. Propably even triple. I guess they have more than one clever lawyer who have investigated every possible scenario during all these years. And I think it is very okey. Would be disaster for their economy otherwise

Perrie Juran wrote: Pamela Galli wrote: Finally, the service provider must not have knowledge that the material or activity is infringing or of the fact that the infringing material exists on its network. [512©(1)(A)], [512(d)(1)(A)]. If it does discover such material before being contacted by the copyright owners, it is instructed to remove, or disable access to, the material itself. [512©(1)(A)(iii)], [512(d)(1)©]. The service provider must not gain any financial benefit that is attributable to the infringing material. [512©(1)(B)], [512(d)(2)]. Interesting question here. If the fees, the Linden Dollar Game Tokens that LL 'charges' the Merchants simply go into the sink (are destroyed) are they gaining a Financial benefit? I know they do indirectly because they operate the Lindex. But the Lindex is separate from the Marketplace. (I have a suspicion that the Lindex is operated as a wholly owned subsidiary, a separate entity legally speaking, from SL. I have no proof of this but it would make sense). You actually have to go deeper into that 512©(1)(B) and 512(d)(2) to get the idea: "A service provider shall not be liable for monetary relief, or, except as provided in subsection (j), for injunctive or other equitable relief, for infringement of copyright by reason of the storage at the direction of a user of material that resides on a system or network controlled or operated by or for the service provider, if the service provider— does not receive a financial benefit directly attributable to the infringing activity, in a case in which the service provider has the right and ability to control such activity " In LL case: service provider has the right, BUT has not the ability to control ==>so LL is on a safe side.

How should any Linden know if the merchant has a license to sell these things, or not? It's up to the IP owner to take action against it, or not. It's nobody elses business. That is exactly correct. And also the content creator's responsibility is clearly expressed inside the SL Terms of Service: "Linden Lab reserves the right, but is not obligated to use technological measures designed to prohibit the copying, transfer, or distribution of Content outside the Service when we in good faith believe that such copying, transfer, or distribution would or might violate the Intellectual Property Rights of our users, Linden Lab, or third parties. You copy and use Content at your own risk. You are solely responsible and liable for your use, reproduction, distribution, modification, display, or performance of any Content in violation of any Intellectual Property Rights. You agree that Linden Lab will have no liability for, and you agree to defend, indemnify, and hold Linden Lab harmless for, any claims, losses or damages arising out of or in connection with your use, reproduction, distribution, modification, display, or performance of any Content."

DerpWolf wrote: Jake Koronikov wrote: (Just for fun: Sometimes take one of your normal maps in photoshop, select blue channel, press ctrl-I, save file and render it inworld. You will get a spooky ghost like effect. If you set your environment so that the sun is behind your object...the front side of the object is lit ) ____________________________________________________________________________________________ That's interesting info. I heard that some renderers do not use blue channel at all. I wonder if we can exploit it to fake subsurface scattering. Well yes, it is actually a sort of a subsurface scattering. I have never been thinking it that way, but you are right. Tho I think the effect is quite strong, so I am not sure if it can be used that way. Another thing is that when I tested that blue channel flipping sometimes in SL, it caused black artifacts here and there - but I didnt test or tweak it any further. Was just a quick experiment. (ETA: I just tested your subsurface scattering idea inworld. It looks like the black artifacts can be avoided by stabilizing the blue channel flip with some actions in red and green channel. But gotta play with it more, I didnt yet figure out the principle how SL handles that turned around face normal. Anyway, purely flipping the blue will cause some artifacts) Yup, and some shaders do not use blue channel directly. They calculate the blue channel vector using the values from the green and the red. If the normal map is correctly baked so that resulting vector lenght is always 1, the third channel can be calculated using only two values.

Masami Kuramoto wrote: As far as I know, a blank map would be <127,127,255>. Any other color will bend the normal relative to the current tangent basis. Normal map neutral color is kind of a tricky thing. Actually the correct answer would be <127.5 127.5 255> but as we know this number cannot be expressed easily in 24 bit space. This comes more obvious if we think the baking process. The normal map consists of 3 vectors. Each vector can have a value between -1 and 1 so the range is [-1,1]. Way to think it practically: For example blue channel contains the normal vector. Face normal can point to any direction from totally backface to totally frontface..so it can make 180 degree turn from back to front. So, this vector has a value between -1 and 1 in vector math. (Just for fun: Sometimes take one of your normal maps in photoshop, select blue channel, press ctrl-I, save file and render it inworld. You will get a spooky ghost like effect. If you set your environment so that the sun is behind your object...the front side of the object is lit ) Well, 24 bit RGB file does not have negative values. To get things work the baker software pushes -1...1 ranged values into 0...1 range. This 0...1 range can be expressed using 8 bit number between 0...255. During this process some data is lost. As you can see -1...1 range has twice as much space as 0...1 range. An example: Original vector is [-0.2, 0.5, 0.1] ==> Packing into RGB would be this: ([-0.2, 0.5, 0.1] / 2 + [0.5, 0.5, 0.5]) * 255 = [102, 191.25, 140.25]. The stuff behind decimal point do not work => the baker rounds the number into 102, 191, 140 Neutral vector is [0,0,1]. After above math it looks like 127.5, 127.5, 255 => Rounded up to 128, 128, 255 Now lets look at this neutral 128,128,255 number in the shader point of view. The shader unpacks it from the file into more suitable -1...1 vector space. The math would look like this: 2 * ( [128,128,255]/255 ) - 1 ==> [0,004, 0.004, 1]. Yep, it is wrong but close enough to correct 0,0,1. How about 127, 127, 255 value: 2 * ( [127,127,255]/255 ) - 1 ==> [-0.004, -0,004, 1] Yep, as much wrong as the previous value. If we take the absolute correct 127.5, 127.5, 255 we get the correct vector [0,0,1] So, in principle there is no difference if you use 127,127,255 or 128,128,255. Both are wrong but close enough and both of them should render looking about same. Sidenote for picky people: The example vector [-0.2, 0,5, 0.1] above is not a correct normal map vector, because it is not normalized. I just didnt have time right now to go into normalizing vectors. Forgive me that - someone else can do it here if needed : ). The un-normalized vector does not affect the math itself.

Jira is now filed: https://jira.secondlife.com/browse/BUG-5975

Just a little addition to Aquila's very good advice - in case you are below ver 2.70 this might work too: In object properties: "Wire", "Draw all edges" and maxium draw type "Wire" (wrong setting in the image below)

arton Rotaru wrote: Handplane3D is nice. However, I get even slightly better results with xNormal, and using an "Unity3D Tangent Basis Calculator for XNormal" (google it), and baking a tangent space normal map as usual. Though, I have the impression the Unity3D tangent space still isn't exactly the same as the one SL is using. @Jake, you should file a jira with your findings. I wouldn't be too surprised if this seam issue is a bug, or flaw in the SL shader code. Thanks for the hint. I will check that Unity Tangent Basis calculator. I made a final test with a quite old software (propably seen it's best before date by now hehe), Nvidia FX Composer 2.5. It allows you to design shaders and write high level code in them. I I think it will not allow you to go in-depth level of calculating tangent basis tho. FX Composer rendered all of these tests just fine, no seam visible. I will file a Jira next week. Just waiting a couple of days if someone finds a reasonable non-bug explanation and posts it here.

Hey Drongle!. That Handplane you mentioned looked like a very intersting little tool. I dowloaded it too and tested a bit. However it did not solve this seam issue ;/. The seam looks excalty same with or without using Handplane. But I found and easy way for you to reproduce this all (if you wish to join this neurotic obsession team of seam chasers LOL) You propably have a standard SL avatar file. Here is a simple workflow: - Use SL standard avatar as low-poly mesh (ETA: Delete the left side of the SL avatar to be exact in this test. There are overlapping uvs in hand and arms, whitch could in theory affect the result -> images below has both sides still, but the result is same anyway) - Duplicate it and make a Hi-poly by just subdividing a couple of times. - Sculpt some random lines across the UV island seam areas - Bake a normal map to this standard SL avatar uv layout, maybe using XNormal,Blender or anything you wish - Import, rezz, set the NM, and Move the sun around to get a shading where light comes from sides, not direclty from up What I get on the shoulder area is a really ugly seam....those damn normals point to €¤%%##¤¤ (sensored). I have made some tests with hard edges, and it is sort of a solution. The reason is that in hard edge there are now two separate verteces on each side of the seam. So vertex on the other side gets it normal from its tangent space, and the other vertex from its own tangent space. And they render well. But of course organic model can not have hard edges thrown here and there. It would ruin the smooth shading totally. So in principle, this is an issue related to single vertex in smooth shading. And that vertex receiving some weird normal from ...somehwere. That normal will destroy the adjasent face normal too, because in smooth shading the face normal is interpolated between vertex normals on each corner of the face. Here are the photos: And the uv layout with the problematic area highlighted:

I think this issue will not be solved without LL comments. As far as I could find out the whole thing is related to tangent basis that is used by baker and its suitability for corresponding shader tanget basis. It is possible that baker calculated tangent basis is different that what shader (SL) expects. Normal map uses a vertex data that is called tangent basis. The normal map has three channels: blue as Normal vector, red as tangent vector and green as bi-tangent vector. Tagent follows usually U-coordinate and Bi-tangent follows V-coordinate in uv-texture-space. During render, the tangent space is converted to actual world space and rendered using final face normal that is received from normal map vector calculation. (or world space is converted into a tangent space, but anyway). Seam verteces are a special case, because they receive two different tangent info from two points in the normal map. Technically the seam area has two verteces, but in smooth mesh only one is rendered tho. But: the face-normals adjacent to seam verteces are affected by the vertex-normals of the seam... Those two points have different tangent space in this cylinder example...because the uv:s are rotated...and do not share same tangent basis anymore. A good guess might be, that SL shader system handles this situation in a different way than baker does. This causes problems when seam line tangent basis is very much different on each side. The smaller difference there is between tangent basis the less visible the seam is. A couple of images: In above example the tangent basis is different across the seam. Many many years ago 3ds Max had same kind of a issue when rendering normal maps. At that time there was a lot of talking and someone even suggested that the shader has a bug. They suspected that tangent space information is genarated after breaking verteces that have more than one uv point. This way the seam verteces do not have same normal anymore. The generation should have been done before the break and use an averaged normal of two verteces, instead of only one. Anyway. I will give up trying to fix this in bake phase. Instead I try to organize the uv-islands another way and use some manual painting in Photoshop green and red channel to make the remaining small seam to disappear.

Yeah, this seam issue drives me crazy . The angle between border edges (edge loop, vertex loop) is the key element. If you straighten this simple cylinder uv border -> the seam disappears. To re-produce it, the uv map has to have angular edge flow in the border and the uv island counterpart flow must be in different angle. A weird setup but very very normal setup in organic shape models.

I tested this with both LL viewer and Firestorm. Same result.