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:

Ah. I assumed you two had Maya 2012, which is why I spoke about SP1. I am not sure if Maya 2009 has a SP as well, but yeah its worth checking out. Your collegue actually knows that you are trying to perform a batch bake on one and the same mesh instead of baking out several meshes, right? Batch bake works for me when I bake several meshes all at once that share the default UV layout settings (the zero to one space). The problem lies in telling Turtle which tiled *sub UV layouts* need to be baked out from the big UV layout and actually doing them all at once, with one single mesh. It should be possible because a) we know Turtle can perform batch bakes in any other scenerio b) its possible to say which UV coordinates must be used when doing a batch bake. Also, given the fact that we can actually tell Turtle which UV coordinates it must use, I would assume the UV sets are not necessary at all. This is because we can easilycreate 8 UV tiles (1 for each material) in the UV texture editor and by doing what you just said we tell Turtle which coordinates it must use, and thus plenty of UV space and no overlapping UV layouts. I have not tried it yet though, I might forget something. As for the texture baking ... Thanks! It was 4:50am or something when I wrote the message above and I was not looking good enough. Shame on me! Now that I will keep baking out textures like this I *must* find out how Turtle can do a batch bake. Will give it a try again after a cup of coffee ... or ten.

Sorry about that. I forgot that I was logged in as Priestt. Priestt = me.

Cool. I'll keep this in mind. I wasn't sure if it would actually work but you just confirmed what I had in mind. Doing a batch bake with Turtle should be possible, for sure. I've little experience with MEL scripting, but I'd guess a MEL script could do the trick. Not sure how, though. From what I understood, MEL scripts allow you to perform a series of actions, thus it *should* be possible to say bake this, bake that, use this settings, use those settings, etc.

Thanks! I will check it out. I have Firestorm installed, not sure which version. Usually I download a version of SL until it wont start up anymore and it forces me to download a new update in order to log in. ^^^^

The UV set editor works just fine. I was aware of this option, but I never actually used it for SL, which is kinda silly of me because it works great for SL purposes. Basically what it allows you to do is laying out separate portions, pieces or parts of your UV layout, into different UV grids. This means that I can create 6 separate UV layouts for each and every individual face of a square box. It also works nicely with Turtle. There's a little drawback though … and that's the integration with Mudbox when working with multiple meshes. In order to paint over several UV layouts, Mudbox wants you to tile UV layouts. You must actually place them in and out of the 0 to 1 space in the Maya UV texture editor, tile everything nicely, then throw it into Mudbox and then (AND ONLY THEN, sadly) you can paint over your mesh without getting overlapping paint layers. Mudbox doesn't attach your paint layers to individual UV layouts, your paint layers would overlap instead. Think about it as one big UV grid in which you have to tile your UV layouts. So unlike Maya (where you can say I want this UV layout attached to these faces) you have to set out by hand (positioning your UV layouts) And this sucks lol, because a) I am a turtle fun, which requires me to use the UV set editor in order to have my materials and UV grids nicely set up b) I usually paint my own textures in mudbox and sculpt high poly versions in it, which I can use back in turtle. I suppose there is way to tackle this problem, but I have yet to test it. What 'should' work I think is tiling everything in Maya just like how it happens in Mudbox. Maya doesn't care whether you are actually in or out the 0 to 1 space, as long as you follow those box/grid lines. So once everything is uv'ed ready for mudbox, I could start assigning UV sets. You would end up with something like: 1 UV set attached to 1 material which has its own UV layout. By doing that I would avoid having those overlapping paint layers in Mudbox and I could tell turtle which portions of my mesh I want to bake out. I hope this makes any sense!

Never mind, got a solution

If you are talking about resizing the UV scales to tile everything nicely next to each other - sure. However, by doing that I would loose texture resolution.

Hello everyone! I was wondering how you bake out light maps when using several materials on a single mesh. I am a Maya user, but I suppose it is basically an issue everyone encounters. To give you an idea of what I mean:Imagine having a mesh with a bunch of faces. I want to apply 8 materials to different groups of faces. After I applied the materials, I need to (and this is how it goes in Maya, not sure how it goes in other 3D programs) lay out the UV shells for each portion of faces that is attached to a material. This means that if I have 8 materials, I have 8 UV shells, overlapping each other. Now here's the thing. When I select the mesh, Maya sees overlapping UV shells. So if I want to bake out light maps, things go wrong because Maya reads one big mess of overlapping Uvs. My apologies if it sounds a bit confusing. Every bit of advice is highly appreciated! :)

That did the job. Thanks! However, because I had to apply 2 materials to my physics mesh, I was 'forced' to create some extra geometry on the psychics mesh, thus a higher PE. For example, assuming I use the max amount of materials, I need to make sure I can apply all those 8 materials to my physics mesh, which means I must have (at least) 8 triangles on which I can apply the materials. This kinda sucks when making stuff where the physics shape can be as low as possible to keep things low prim. On larger builds however, where you end up with plenty of faces for the materials, it shouldn't matter.

Could you explain that? I don't know what you mean.