StoneDwarf

Thanks Kwakkelde and Drongle. Even though I am not getting any wiser from all the terms you two are throwing at me, I think I am (very slowly, lol) coming to the realisation of what you two are trying to explain. My gratitude for all your patience. So like, whenever we are dealing with meshes that are going over the 0.500 download weight, it is worth checking out what the results are when they are uploaded as seperate meshes, and part of a linkset, instead of (what I thought was the most cost effective way) making them part of an even bigger mesh?

I am confused, then. Why is it that my 'combined' mesh has a LI of 2, and the linkset comes with a LI of 40?

I would not say just with simple tables, though. From what I understood – though I would appreciate it if you point out my misinterpretations, if any, of course – HD explained that his decision in how to split things up was mainly based on scripting and functionality purposes (what needs to rotate, graphical customization, etc) And that's alright – its a requirement in order to archive what is needed. The link below is a wip on some architectural work I am working on right now, and I can assure you that if I am going to upload the pieces separately, with separate LODs, and with separate physics shape, the PE will be insane. However, if I combine, for example, all the windows, combine the stone bricks on the sides and everything else etc as much as I can to the point where I am running out of texture resolution, I will end up with a much lower PE. http://imageshack.us/f/837/textured.jpg/ To demonstrate what I am talking about, trying creating 80 boxes in your favorite modeling program of choice. 10 rows of 8. Combine everything, leave the physics and LODs on default, and check the PE. Now try doing the same without combining everything. Even the file size on your computer will be entirely different (287KB for the combined boxes, 472KB for the separate boxes) My point is that people should realize this whenever they are going to make stuff that is not scripted. And I would assume that “everything that is not scripted” is not just simple tables.

Hm well, you might be right as far as the scripting part goes. I have little experience with such scenarios, but I will take your word for it. What I specifically meant was – and I might have worded it somewhat confusing – that in 9 out of 10 cases you will end up with a lower PE by combining several objects into a single mesh in your 3d modeling program, instead of uploading them as separate meshes and combining them into a linkset in-world. This is because (and I am not sure about the exact numbers or names, but I assume you know what I am talking about) each mesh one uploads has a minimum prim count (download weight, server weight? Forgot how it was called) of 0.500, which would be one. If, for example, I am going to build a table with 4 chairs, I would end up with a lower PE by combining the whole table set into a single mesh, than how it would be if I uploaded 5 meshes (1x table 4x chairs) Depending on how you are using the LODs and physics shapes, you can end up with half the PE if everything was combined in comparison to how it would be if I uploaded everything separately. I said generally, because it depends on the situation. If, for example, I am going to model something low poly, it does not matter a lot. A set of two low poly chairs uploaded seperetly for example, will end up with a PE of 1 anyways once they share the same linkset. What I have experienced with my own builds (mostly large architectural stuff) is that I literally can cut down PE in two by making smart use of what I described above in combination with the 8 materials per mesh thingy.

Heya Kwakkalde, Not sure if you understood me right, or if am understanding you right, or if I am simply mistaken. What I meant was is that you generally archieve a lower PE by comining stuff into a single mesh instead of seperate meshes.This is incorrect?

Heya HD, Thanks for clarifying this up. Based on your (in depth!) information, you seem to have a good solution for all the goals (or problems, depending on how one want to call it) in such a way that it is SL-friendly and fulfills the needs of your customers – and that's what counts. About the scripting thingy …. Yeah, see that's what I forgot. Combining everything in one single mesh might be more prim efficient, but it will result in less customization as well. Its one of the things one must take into account whenever we start with modeling vehicles. Common sense for most people I suppose, but the chances are that I would come to this realization once its too late haha. Thanks for pointing that out! Well done, and thanks for covering all these topics!

Heya HD, I think – and this is not meant to be taken in a negative way – that you could do an even better job by utilizing materials and textures more efficiently, and thus archive a much lower prim count. I could be wrong, though, it depends. For example, are you using textures? If the answer is a yes, you should be able to get away with something around 256x256px textures throughout your model.These dimensions allow you to throw 16 tiles of 256x256 textures in one single material.This means that you should be able to throw 128 textures in one single mesh (16 tiles x 8 materials = 128) Based on that, I would assume that you should be able to model 80% of your work in one single mesh. I am a big noob when it comes to scripts so I dont know if you need separate parts with separate physics shape etc, but I would highly recommend that you do all the detailed work (the engine, for example) in a single mesh. Another thing to consider are the LODs. The engine, as how it is now, could be boxed out on the less detailed LODs.Based on all this together, I think – but I could be entirely wrong – that you should be able to archive a prim count of 15. 20 at max. But again .. I am a noob when it comes to scripts. I know that scripts can contribute to the PE as well. I'd appreciate it if you post a bit more background information. I yet have to start with (scripted) vehicle meshes and would like to get as much as information as possible before I actually start with it. Anyways, I like the design. Proportions seem to be accurate. Good job with the texture detail on the tires and the engine looks cool as well. Personally I would go a bit further in terms of details, but you did an awesome job already nonetheless. Looking forward in seeing more of your work!

Check out:

This, yes. On a side note: Exporting meshes with the standard DEA_FBX plugin will just work fine with Second Life, as long as you are using just one material. If you want to apply several materials to one mesh, you must export as a FBX and run it through the converter. What I usually do whenever i want to inspect my build in-world (and to get an idea of the prim cost) is combining everything, exporting in DAE_FBX format, then upload. Once I am going to upload my finished model, I do the steps Daniel described. I am not sure about choosing 2011 in advanced, though. I have mines set to 2012 (by default) and never experienced any troubles with it. I am not sure why it would be needed anyways, because the converter converts the while, both the 2011 and the 2012 version.

That does makes sense, yeah. Do know that the confusing interface of Blender, is only temporary. Its possibilities however, and its results, are not. Plus, once normal maps will arrive in Second Life (which will happen most likely at some point) you will be armed with all the tools one needs to model, UV, sculpt, texture, rig and animate a mesh. And with the Machimatrix covering your back, things simply cannot go wrong!

Chosen Few wrote: I'm beginning to rethink my approach. As I now see it, the best strategy for models that will need many textures is to do a combination of both techniques. Before exporting to Mudbox, arrange everything into tiles. Then, after re-importing back to Maya, copy each tile to its own set, and move everything back to the primary shell in each. This extra step is again a bit of an annoyance, but not a showstopper. This, yes. I can only hope you have plenty of resoruces available to move those 9999999+ poly meshes, otherwise it will be a showstopper. ^^

The biggest difference between sculpted geometry and modeled geometry is that sculpted geometry ends up in a normal map. Base meshes however, the meshes that will receive the normal map, are modeled. There are exceptions, of course, and there are many artists who simply start with a base mesh in their sculpting program of choice and start sculpting away. But I can assure you that 9 out of 10 times – during, for example, character visualization – people start with modeling a base mesh in an actual modeling program, then begin sculpting and not the opposite way around. Second Life however, does not support normal maps, thus we must improvise. We simply bake our specular maps, normal maps, bump maps yadda yadda into a single texture and hope for the best. Nonetheless the priority of getting your base mesh right and then the details – obviously, in that exact order – remains the same. And you are right about the poly painting, yes. It is a very powerful feature and allows you to paint stuff without having to worry about UV maps, unlike Mudbox, sadly! I keep forgetting about that feature, although it is probably one of the most often used features. My advice would be, though - but this is just my own opinion - that you pick up a modeling program and use Zbrush for sculpting and texture purposes. Even if you figured out how to do the material tricky, granted it actually is possible, of course, your workflow would profit tremendously. On that note, have you tried Blender? Surely Blender is capable of doing the material thingy. If you feel comfortable with Zbrush and just need to apply a few materials in preparions for Second Life, I would throw it through Blender. Cgsociety is a website, with a forum. I would bookmark it, pet it, love it and cherish it. The amount of information, inspiration, tips, advice and tutorials you will find there, is priceless and for free!

I think you misunderstood me. The reason why I asked if you used Zbrush, is because Zbrush is not a 3D modeling program. Zbrush's sculpting tools is what makes the program one of the best sculpting programs available at the moment, and sculpting and modeling is everything but the same. With this in mind, I wondered why you would use Zbrush for such purposes like you just described. However, if it works for you, you should stick with it, of course. As long as the job gets done it should be no problem. But because of the problems you are encountering, I am wondering if you are taking the right approach. I would assume there are many Zbrush users who are reading this topic with us, and given the fact nobody has posted a solution for your specific issue, sadly, you might understand why I asked why you were using Zbrush. I am not familiar with Zbrush, so I can't say whether you are doing things right or wrong. I just hope that you achieve the results you are looking for! As far as me using Mudbox as my modeling tool – no. If I would have to describe Mudbox's purpose in my current pipeline, I would say its an essential part of my texture process. I am a fan of hand painted textures, which is why I use Mudbox. Plus, I can sculpt details in high poly meshes that I can bake into my low poly mesh textures. Have you tried cgsociety's forum?

I still have a problem though. I now know how to tell Turtle which UV layouts I want to bake out. And while I was learning this, I also learned that (from what I have understood) there is only space for 4 UV layouts, instead of 8. You can, of course, throw in as much as you want, but you won't be able to bake the textures out separately Multiple UV sets might work you would think, but by doing that it wont coorperate with Mudbox because Mudbox want a nice collection of UV layouts tiled next to each other, within one UV set. See where my problem lies? What I am trying to say is that in order to bake out all 8 materials with Turtle, you *must* use UV sets. Problem is, though, that Mudbox doesn't work with UV sets, it instead wants you to import a mesh with all UV layouts nicely tiled next to each other Any tips? @ Toysoldier. Multiple texture surfaces? I assume you are trying to do the multiple materials trick to end up with several faces in-world, right? If so, why would you do this with or in Zbrush?

An internal sub-licensing mismatch? oO But yes, updates might be the problem. I am using 2012 though, which comes with a different version of Turtle. I think its an error on my side, and that I am doing something not right. About the UV settings ... I am playing with the UV range settings which seems to be pretty straight forward, but I am not getting it. :matte-motes-evil: I used fluffy rainbow colors to keep things interesting, but I keep ending up with blue, 2 times half a UV tile yadda yadda. Edit, Never mind it, figured it out. I didn't realize I had to fill in negative values in the MIN sections :matte-motes-big-grin: