Codewarrior Congrejo

@ Charli - They 'look' like flat textures when you only see it in a 'screenshot'. But the effect of a normal map goes further. As light and shadows are being casted over these textural created details in the model. Means they behave just as any 'real' detail and light and shadows keep wandering across it when you move. But aside from that normal maps are just 'one part' that makes a model complete, and can't take it as far as displacement maps (regular displacement or vector displacement) could take it - those can actually 'move' the geometry and thus visually 'deform' the object, by adding visual geometrical detail. Thereby a normal map will allways look 'flat' from certain view angles, but as it acts like those details would be there in terms of light and shadow it adds a lot to the whole feel of being real. Have a look at this video then you will see how this looks 'live and in movement' Since you weren't aware what normal or specular maps are: Normal maps: It's a technique used to fake the lighting of bumps and dents - (an implementation of bumpmapping) It adds more visual details without using more polygons. Thus can greatly enhance low polygon models. Specular maps: they define shinyness and reflections of light like the bright light dot you see on a polished billard ball. With specular maps you can visually shape the specularity of a model in certain spots. (like the the forehead of a human normally has more specularity / shinyness going on, and leather is behaving different from metal etc) This way you can have it all still in the same shader but just take the specularity values from a texture / image and having different areas look individually - instead of applying the same specular behavior for all parts in this certain model. And yes they are 'textures' (image maps) that are being used in channels of the material / shader in order to create certain visual effects. Example Diffuse map (color map) : http://www.3dtotal.com/tutorial/zbrush/makingof_zenoth_alien_from_jupiter/images/image_10_character_uv_skin_texture.jpg Normal Map: http://www.3dtotal.com/tutorial/zbrush/makingof_zenoth_alien_from_jupiter/images/image_07_colour_uv_map.jpg Specular Map: http://www.3dtotal.com/tutorial/zbrush/makingof_zenoth_alien_from_jupiter/images/image_11_character_skin_bump_specular.jpg

Hey drongle; Regarding the instance flag - (bare with me - i just got up : )) I think it was Nyx Linden mentioning this back in that time when being asked if the use of instances could be implemented in order to save drawcalls. And i think it's really just meant the way that it 'respects' the flag (when being delieverd in the collada file) but breaks it down into the internal system. Thus as you said, ..deciding what is a 'prim' without reference to the loss of independent transformability.. Which would also explain why it is basically the same outcome no matter if it was instances or copies (like in your tree example) The toggle you suggested would have been nice, not only for the download weight but also for possibly - if taken even further - the handling inworlds, by i.e. applying a new texture on one of the instances within that resulting one object (no linkset), and changing it right away for all instances of that sub-part. Concerning vertex splitting, as discussed in one of the links you gave - In SL, this all takes place before the model gets uploaded. That's why people often ask about the unexpectedly high vertex counts in the uploader. The effects are thus already reflected in the download weight, which should incentivise people to make exactly the kind of optimisations suggested in the linked page. That is one beneficial result of the internal upload format. It makes for a good correlation between download weight and render resouce use. Correct. And to add - still takes place in the renderpipeline, which was the point i was making, as people generelly tend to forget (or are unaware of ) about the effects their models have in terms of rendercost, independent from the secondlife-internal costs (like landimpact). And correct also about the displaying of all 'additional' vertex sources in the uploader - which should normally make them consider the reasonability of their model. But i think many really do not understand the whole concept of 3D, how engines handle things internally and terms like renderpipelines etc. So it's probably just natural they simply are left wondering why the vertex count is so high and assuming there is something wrong with the uploader, or their model would be messed up somehow.

You can have a look here (if you did not already) : Rigging Thread (Mesh) There i am explaining how i made a non human model fit to the SL skeleton and which things are important to keep in mind. regarding custom animations or how to avoid that need. And here a general starter tutorial for blender : http://www.youtube.com/watch?v=bqW3BBRu1DI But it would be best if you could explain 'what' kind of creature you are trying to rig. And maybe post some screenshots of the model here in this thread. And what you got so far / where the problems are. regarding your PM to me, you 'can' modify the skeleton. but you can not add more bones to it for the ingame usage. And most modifications or deformations result in the need of custom animations for this rigged model. If you could provide us with the information what you are trying to achieve, some screenshots etc, as said - that would make it easier to give you tips of how to do it or if even possible.

(yeah the quotes sometimes seem to not like us, that's why I also mostly just copy and paste it manually) But to answer your question: (I'll try to make it understandable .. Quotations on 'try' lol) - an instance of an object is basically like a 'live link' between those 2 objects. Which means: the original is always equals the instance and the instance is always equals the original - Instances are being used when the exact same object appears more then one time on a scene. Note: that is nothing you can control it's defined by the engine. Unless an engine allows to deliver instances of objects to be flagged as such and imported (i'll come to that later in this answer) (also some 3D programs allow internally to create 'instances of objects' to easily address them to do something all at the same time and in the same way, like changing all of their textures at once and so on) - lets say you have a landscape and there are rocks all over the place, then it's beneficial to have them as 'instances'. If you need to change their textures you can do that by simply changing the texture on the original. - Some engines make use of optimization and use of the fact that it's the same object with the same properties to lower the drawcalls. (when the instanciated objects meet the requirement of having 100% the exact same properties) This process is called Drawcall Batching. - Regularly every object (mesh / model) is one drawcall, no matter if texture or not, but without batch optimization, every instance of an object is also one drawcall. With optimization however, if you would change the instanced object just in the slightest way (i.e.. scale it uniform or non uniform or anything else that would change it) you break this 'connection' of optimization and it will create an own drawcall again. Hence - my sentence : that even instaciated objects can have each one own drawcall > even when having the exact same texture. - About drawcalls: Your video card can only do so many of these per rendered frame and keeping this low is having a big impact on performance. A draw call is done for each material on a mesh every frame. One mesh doesn’t equal one draw call. A lot of engines actually limit the number of materials you can put on a single mesh. The old Nvidia Series 600 could handle 600 drawcalls per frame. Newer series can do 1000, and so on. - In secondlife all objects are editable / scalable / texturizeable, thus SL did never intend this kind of batch optimization for the render and streaming pipeline. (and as being said, the slightest change on the instance of the object already breaks this anyways and creates a new drawcall) - All you can do is to change the diffuse / the texture map being applied to an object. (and in future the normal and specular map, but its still just one shader) the shader stays the same. As of 2011 it was mentioned that SL respects instance flags in uploaded collada files, but the resulting instances would be able to be scaled / modified / limited independently from each other. Using the same model multiple times in a build can thereby save downloading / loading times. But this only affects the downloading time, and not the drawcalls or rendering pipeline. - SL offers on the other hand a version of drawcall batching: in the advanced settings : RenderMaxTextureIndex this controls how many textures can be combined into a single batch (Setting it to 0 will effectively give you 50% more draw calls. On certain systems, this can result in a fairly big performance break-ins) But > to quote the SL wiki about Culling here : ..."The other major limiting factor for performance in SL is the small batch size. On average, SL draws about 70 triangles per drawing call. In theory, increasing that number to 200 triangles per drawing call could improve rendering performance by 200%. The primary reason the draw size is so small is because we have to break batches to switch textures and to sort transparent objects to be rendered in depth order. " That is (as he states there too, one of the reasons) why modern game engines (the game: RAGE was one of the first ones to do that) are so much into something called 'megatextures' - by making huge textures of 8000 pixels² and even more , they combine i.e.. a whole landscape or scenery onto one texture / texture atlas, to optimize the drawcalls. So that the whole geometry can be rendered in one single draw call. And to quote once more one of the LL Devs stating this : Since textures in SL are streaming, though, generating atlases for your builds will result in ugly artifacts as textures load, so the correct solution is probably something between megatexturing and atlasing, where atlases are generated on-the-fly by the viewer and tailored to align texture borders within the atlas along mip borders according to the amount of the texture that's been downloaded so far. We've (somewhat intentionally) done a very poor job at Linden Lab of educating builders on how to be performance conscious, which I think plays a large part in the overall sluggishness of the viewer. This is part of a philosophy that says it should be possible to build a content authoring system where artists don't need to care about performance implications, as the software should just deal with whatever comes its way appropriately. What we've seen, however, is that people (even technically minded people) consume as many resources as are available to them until performance reaches a level they deem is unacceptable, so the more efficient your renderer becomes, the more ludicrous the demands become. In SL, this usually means the performance becomes that of the lowest common denominator in terms of what is acceptable. <--- my personal opinion: a wise guy saying this ^^ Long story short : Textures are still one of the big banes of our 'graphical' existence and in the render pipeline. (next to vertices) And people are completely unaware or not interested in thinking about this. Even though it should have made them wonder when they have ever seen textures of game props or character texture skins, why the game artists cluster as much as humanly possible onto one texture. The amount of drawcalls some item creators force onto users graphic cards by immense amounts of drawcalls for even the smallest items (as in my example putting 1024x1024 textures on every single prim of an earring, causing 20 drawcalls just for that little thing - where others would have created a full landscape by using that) instead of using 125x125 pixel textures for those small parts to minimize - if not the drawcall itself - then a least the memory the texture takes up in the rendering process. (textures have to be redrawn, and rewritten into the graphics memory / cache very often - the smaller they are the faster it goes of course) This is at least one of the reasons why there is and has always been so much graphics and in some cases still bandwidth based lag. Here is another interesting article I keep referring too, regarding what actually goes into the render pipeline, and why too many vertices are bad, and too many UV seams and materials etc. http://www.ericchadwick.com/examples/provost/byf2.html And since the whole drawcalls and UVs kind of can go hand -in-hand on mesh models something to take into consideration when creating UVs for models: http://answers.unity3d.com/questions/14578/whats-the-best-way-to-reduce-draw-calls.html Regarding the use of the same texture space several times from the same texture when a certain pattern or area can be repeated on a model or subparts of a model. (Overlapping UVs in order to 'reuse' the same texture space etc) . And here is a full PDF about drawcalls and instanciating: http://http.download.nvidia.com/developer/SDK/Individual_Samples/DEMOS/Direct3D9/src/HLSL_Instancing/docs/HLSL_Instancing.pdf I am not sure if I could make it understandable enough for you - but I tried =)

yeah that sounds reasonable. What you could try is to go to mesh sandbox 3, or 6 or 23. I normally build there and don't have much issues to rez. Could as i said be the simulator making trouble. Give it a shot and try it in another region.

You're welcome. =) But Madeline has a point here too. Secondlife is changing to server side baking soon. And thirdparty viewers will need to update at that point. But as i said even with the newer viewers you can still try to run SL, but you most likely will need to lower your graphic settings, and find values that makes it run stable without crashing with your machine. So no reason to give up : )

yikes ! what on earth.. no.. ...or ? i don't know.. i am confused.. can't stop looking.. i don't want to look like this.. or maybe.. I DON'T KNOW anymore.. that nose!!!... *faints*

@ Rahkis, glad i could answer that along the way lol. And your answer - answers my question if it's finally fixed as well - as i assume it's not : )

How do you select a face on the object if you can't rez it in aditi? I drag it from my inventory to the floor and it doesn't show up even though the region allows object rezzing. Now that can have various reasons: - your normals are flipped and the object's outsides appears to be invisible to the renderer. - try to cam around and see if at least anything is visible - The object was too heavy and the server did not load it. (in that case you'd normally get a message after a while telling you that the rez failed... or will rez after a while - The object got some sizing issue, and somewhere along the line of exporting it back & forth of milkshape and 3DS it got either hilariously small or extremely huge . and its either to tiny to see easily or it's so huge that you are standing somewhere insides and can't see the rest. - The simulator could be having an issue and rezzing is failing at the moment - your graphic settings in the viewer need to be adjusted ...but all i can do is guessing from here, so i have to ask a question first again: Did it look normal in the upload preview window? Did it maybe have an extreme high Landimpact ? ( that could be a hint to being of very big scale) also check the scale values in the uploader

for the all those prims we wear, no one seems to much care. nice rhyme ; )

You just opened this account i believe, things might need a moment until they are fully upadted. And depending on the age you have given (if under 18) the maturity settings will nto be available for you. Apart from that it also depends on your viewer. For the official SL viewer it is here: http://community.secondlife.com/t5/English-Knowledge-Base/Maturity-ratings/ta-p/700119

haha, i'm glad i could find you some new purpose for that poor texture of yours becoming all dusty in the darkness of your inventory =)

Unfortunately i have to join what Kwak said regarding the fact that it all depends on what excatly you want to achieve. And that there are no 'easy - working for all cases' settings. Sometimes even different parts in the same building require different treatment to get the best results. Dark borders can result from many things. That i have assumed you are trying to do AO bakings is maybe based on some missing informations. Try to explain what exactly you are going for, and at which steps you get exactly which errors, that makes it easier to give some tips =)

yeah sounds pretty much like you are either mising some settings in the exporter, or something back and forth from milkshake to 3DS goes wrong. The textures insides SL are 'supposed' te be applicable in 2 ways. One: the regular way.. you upload your model, and then you upload your textures. you select a face on the model and apply your texture to it. Just as you would with every prim. (depending on how many materials you created > 8 is the maximum on 'one combined' object, a mesh can have up to 8 texture faces , and thus 8 areas where a texture can be applied to) Second way: (apparently was broken a long time) is to choose to upload the textures along with your model in the model-upload window of SL (last tab > there you can choose to 'include textures')

noooo ! not my beloved computer! please ! even though the thought my computer could send a visual signal all the way to outter space, sounds appealing.. just noooo!

Heya coby, of course a nicer layed out topology will make it more 'conclusive' when you want to do the copy avatar faces - to - create- clothing method. You might have misunderstood me a bit here : I was just making aware that also with a new avatar you still have to take it's topology and edgeflow into account when you want to avoid clipping or misbehavior while being in an animation. (the closer you stay to the same edges and even vertices in the important spots - no matter the quality of the model - the clothing item will of course work better with it). Maybe you got my point now =) And no there is no such rule.. except the one where i would like to slap onto some fingers when seeing some weird topology or extremely dense meshes.. but that is something i most likely would have to discuss with an anger management trainer >.> *laughs* But apart from that I stick with Rahkis and repeat my own statements I made in the past. The avatar isn't too bad of a model. I've seen others from games where you'd say that looks awesome.. and has even worse topology. It's always a matter of creating something that is optimized for a certain usage and engine. And most games actually 'trick' the eye by using very limited animations that do not reveal the issues or critical parts on their models, or by using different models for different extreme animations. Where they spare i.e.. more polygons on the legs and put higher density on the arms and so on. All of this to keep the model itself always at the required amount of polygons for the use in a certain engine. Meanwhiles the Avatar in secondlife has to be an all-round usable figure, no matter the extreme poses users could create, they can't fall back on tricks and tactics other games or engines would use. About your -quote- "whining" (let's better call it your personal wishing - that sounds nicer : )) I think it had been stated very good on another spot, why the avatar isn't something so easy to replace. Second Life wants to keep the 'shared experience' and downwards compatibility. And unlike 'regular' games where you just install an all-new-version, have new content - secondlife is nothing like this. The problem lays within different things: New avatar = new UV layout. you can 'try' of course to match them a bit up again but generally the rule stays like this : no old clothing items, skins, etc will work anymore with the new one. Additionally the whole weighting for everything being done now would be gone to waste and the same with animations. Almost all the content created over the past almost 10 years would be worthless. What happens with old avatars, should we have both (new and old) in the engine? that just gives even more confusion and blows SLs system up even more, by keeping track of 2 different weighting systems, skeletons and all other internally handled procedures. I know it always sounds easy, but you have a bunch of creators having spend time and money into their creations, wanting a perfect solution so not everything they ever made goes to waste. And you have existing users, who don't care for mesh or new models and just want to be able to use everything they ever payed for. Not an easy decision and surely nothing that could be switched within the blink of an eye. There have to be made a lot 'stable' solutions and decisions most users would be okay with at the end, before replacing one of the 'core' elements. =)

In the last instance should nothing help and there seems to be a problem with the item itself: the best is to contact the creator. (who that is you can find out by rightclicking the object in your inventory and look at its properties).

did i hear high poly and lag? to add to the other answers: *takes a deep breath* Let's differenciate, lag can be caused by different things: server lag and lag due to too many things summing up in the render pipeline and thus lagging your experience and controls , or other hardware based issues causing any type of lag. But since we are on the topic mesh let's skip severside or connection based lags and get into the things that can lag you regarding graphical (GPU) and processor (CPU) impact. Lag is allways an experiences that differenciates between one computer and another. Depending on how powerfull the hardware is. What lags one person with a slow computer doesn't need to lag another. But in general the rule stands: the more to render, the more lag potential is apparent. The amount of polygons of course has an impact for your graphic card to render - the more polys - the more your graphic card has of course to do. Even though it has to be mentioned that the polygons / faces themselve are these days rather the smaller problem, but the vertices are. And of course the more polygons a mesh has the higher the amount of vertices. Tons of UV seams and smoothing groups or material groups can add to this. The whole thing becomes even worse when those overly polygon'ed meshes are rigged. Because now also the CPU has more work. And Graphic Card and CPU have to update and render all the faces, keep track of all the positions of the vertices and much more. As the others already stated: unfortunately not many 'creators' actually have a clue or are even interested in learning how to produce 'reasonable' content - fitting to the requirements and limitations of a certain engine (Secondlife in this case) Thus what we see is a lot highly dense meshes, that drain unecessarily on the users graphics and render time. so long story short > hilarious high amounts of polygons are of course one of the number 1 lag factors. (especially when you take into account that there is not only this 'one' object to be rendered, have 20 avatars with too heavy meshes in your view and your mashine has a 'lot' to do to render all this) PS: i would like to add something at this point that often goes a bit under in the discussion about high poly vs low poly. >>> Textures! People already didn't really consider this back when they only had prims available. Texturing every little piece of an earring with a different 1024x1024 pixel big texture.. adding up like 20 Textures, that other games would use to literally texture a whole szene or landscape. And they now proceed doing it this way on meshes. Making high polygon objects with way too many texture maps / materials. “draw calls“ is the magic word here. Your graphic card can only handle so many of these per rendered frame and keeping this low is going to have a big impact on performance. A draw call is done for each material on a mesh every frame. One mesh doesn’t equal one draw call. A lot of engines will actually limit the number of materials you can put on a single mesh. It also has to be mentioned that even instanced meshes with the exact same materials will require separate draw calls. So if we add this up now with meshes in addition: Means too many textures (drawcalls) and on top of that too many polygons and thus vertices in the renderpipeline > there we have our lag. So yes, as you noticed yourself already that one dress can decrease your performance a lot. If you imagine 20 avatars wearing the same and appearing on your screen, the answer stays yes : )

Addition: ok after re-reading, i assume what you do is building in milkshape, then transfering it to 3DS to make the export from Max into DAE. And when i understand it right, your model doesn't show textures when you try to open the same model back in milkshape (the you formerly exported) ? But it shows all mapped textures when you open the same file in 3DS - just gives an error when you try to do the DAE export? Just trying to wrap my head around at which point exactly the issue happens. So gonna wait for your response.

lol points 11. and 26 made me laugh : ) exceptional explicit problem description ^^ Apart from that try the exporter Kwak suggested. if you can't get it to work, and since your problem appears to be the texture export, you can try exporting it without textures and just save the images separately. The include texture in the uploader window was kind of broken for so long, that i don't even bother trying to upload them along with the model anymore. (In case that is not valid anymore and that include texture finally works flawlessly, someone poke me that info pls ) PS: when you deleted the material and renamed it, you need to assign the textures again. otherwise it won't know where which texture is. Also what helps is to have all maps in the same folder where the export /model is. Some programs can't recieve texture-links, and just replace it with a white texture / default image. The fact that it's white shouldn't be related to it being a PNG, unless its a fully transparent image and can't be rendered in the 3D viewport in the working mode.

This error normally appears when the simulator is offline on which you have been trying to connect to, so you did right by trying to get into other locations. But apparently it can also happen when the viewer's cache is corrupted and can't find the last related information to send to the server. In that case try to clear your cache Me > Preferences > Advanced, clean cache If that doesn't help try to make a clean install of your viewer. (http://wiki.phoenixviewer.com/fs_clean_reinstall)

Did it solve it for your friend with the same steps ? If you are the only one left with the issue of not being able to see the objects try a clean reinstall of your viewer: http://wiki.phoenixviewer.com/fs_clean_reinstall (this is for firestorm but the procedure is almost the same for all viewers) If i understand correctly you only removed some objects, but other objects you did not touch visually dissapeared for you right? But since this problem appears for 2 of you guys. I am having the feeling that this also could be the region cache making some trouble. If the objects are yours you could ask the region owner to return them to you and then place them again, and see if they become visible again. And / or ask the region owner to restart the region if possible. In the very last step you can also submit a support ticket, give them the exact name of the items and the region they are in and describe your problem exactly. (how it happened, what you did, and what the problem is now) > https://support.secondlife.com/create-case/

The latest available viewer and thus 'highend' supporting all new features in SL for mac OS is this one: http://secondlife.com/support/downloads/ But on the other hands your machine is not really strong. Especially the graphic card. And so handling all visual perks in secondlife might become hard for you. (Especially shadows, sice they are very heavy in the renderpipeline) Thus viewers based on older technology (auch as the old Firestorm version you are currently using) are defenitally better for supporting older and / or slower hardware. And this also might be the cause why some viewers keep crashing on you, because you need to adjust the settings to your lower graphic specs, and disbale all functions (SSAO, Depth of field, possibly even disable shadows) to run smoothly and crash / lag free.

if you plan on gaming mostly with a laptop and use it as replacement for your current full computer. Then the point of Peggy stays valid. PS: and 'tablet' computers are another step down. They are not the same as laptops. If you consider a mobile device for gaming then you should at least look for 'laptops'. You will have to look in the highend sections and for gaming laptops in certain to be able to provide enough power and graphical memory to run games at least close to what the power of a full computer can offer. Another point to rake into account is: on a computer you can easily update your graphic cards, in laptops however you can still not so easily do that and in some cases not at all. Which means you need to buy a new laptop whenever you are out of date instead of just purchasing a new card or other parts. Also be aware that laptops do not have the same cooling capabilities as full computers do. They tend to run very hot when playing demandig games using other demanding software. In any case and even with a gaming laptop i would suggest getting a 'laptop cooler plate'. Some of the mobile graphic cards are strong enough to pull off games, but they will allways be behind the power of computers, and in some cases are not supported by certain games or engines. With keeping all this in mind, you should choose wisely what you buy, and read on consumer tests and reviews on those devices before deciding =)

Sounds like the graphical or viewer cache has been messed up when you deleted some objects and others all of a sudden become derendered. Try (both of you) to relog (close secondlife and then log back in) If that doesn't fix it, teleport to another location and teleport back. If it still appears to be not visible to you. Log out of second life and clear your viewer cache. Depending on the viewer you are using, for the official Secondlife viewer it's Me > Perefernces > Advanced > Clear cache