Phoenix Steampunk

Vivienne Schell wrote: I thought this Forum is about Second Life? Please go to the Autodesk and Blender forums and ask the people there to add a "Second Life" section. Well this is the Mesh creation section, so expect people to talk about workflow related stuff and their request to get this part of the forums a lil bit more structured. I am wondering that after over 6 months there is still no sticky with at least the links to the office hours transskripts so people at least got the chance to get updates on whats going on before they repeat the same questions over and over again, just cause the answers get lost cuz of missing subforum structure.

Gotcha, yeah the import still reacts somewhat critical if you don't take care for scaling your model SL ready before uploading, strechting ISL still results in some strange behaviour, might take them a while till they look into that.

Please add some more Sections to this forum. This section of the forum is going to become more and more time wasting with parsing threads for something important. At least some kind of undersection for the different 3D applications Blender, Max and Maya would be appreciated. Some general Questions and some Random Section as well.

*chuckles* If you find blender complicated, try one of the other. blenders problem is just the GUI and the nonconform keyboard layout it uses, comes with blender being developed by coders and not by designers that actually need to work with it.

Hey there just is no official Skeleton from LL out there. The most reliable source for now is to start from the official + blend files and import your model from there and just fix the typical porting issue works quite nice. What nice about the blender avatar file is that it stores all the weights for the base avatar already and sometimes I find myself to just transfere them as well, so I don't have to waste that much time to draw an entire new weight map in Maya. Anyway, since LL doesn't really care to set standards themself by introducing a Next Gen Avatar Base and a much more flexible bone system that would allow creators to add bones to the avatars base. I am still wondering why LL didn't just add extra bones to the avatar to do the avatar mass shaping, but went with stupid vertex weighting groups that noone can Import as part of the mesh.

Fill a jira if it is a consitent problem you can repeat with more than just on rigged mesh and support them with as much informations you got. Mesh project isn't final yet, so don't expect everything to work.

Yep you babbled to much, pic would have been enough The jointsize of the imported rig is just to big. Maya Menu - Display -> Animation -> Joint Size...

Utilizator Mode wrote: so yeah, does anybody know where i can download the older versions of the mesh project viewer? nothing i download from the sl wiki lets me log in, tells me i need to download 3.0, is there a way to bypass this? You should always use the latest version of the importer. Jumping back to an by now outdated version just cause it worked back then doesn't mean it would be a fix. What kind of software do you run and do you use for exporting your meshes? Maya 2012 user have reported issues with the build in DAE plugin that wouldn't be supported by the SL importer since its based on a newer version of the dae. Even tho meshes exported with it could be uploaded it caused issues with materials as well as rigged meshes. Correct me if I am wrong but the latest supported version that SL supports should be DAE 1.4.1. Their workaround was to export their model as a 2011 FBX and use the external FBX Converter to produce a SL valid DAE. At least the clipping issue might be based on that. The latest dev builds can be found here: Mesh Development Builds As for the other weighting problems that have been mentioned. I didn't run into any issues like those that have been mentioned with the latest dev builds (3.0.X - 3.0.3 (239683)), but then I havent done test with multi LOD rigged assets yet. At least for single LOD rigs for me it seems to work as intended. (Sidenote: The problems with the arbitrary verts could be based on ghost verts that aren't asigned to the rest of the geometry, lamina or zero faces. But since you guys mentioned you have double checked everything I doubt its an issue of unclean geometry before weighting. Weird.)

It was pretty much the last thing that charlie did mention at the end of the OH that the aditi mesh sandboxes would be disabled tonight and most of them are gone since last friday, its pretty much just the center core that was still available earlier today. Not sure how it is right now I am locked in a constant login crash cycle with the lastest development build atm. [13:06] Charlie (chalar.linden) remember - mesh sandboxes go away this evening! I don't really like the idea of not at least one mesh exclusive sandbox at all. There are some kind of tests i rather wanna do in a dedicated environment just for meshes than in other parts of the aditi.

Gaia Clary wrote: Poenald Palen wrote: Does one LOD only (as proposed by Ms. Clary) mean a user can not use the sliders or debug settings to lower the LOD of that object? I bet that will not fly at all lol. But, I understand the streaming time would be far more desirable for 95% of users! But well, you are right... We should look on LOD in terms of "User adjusted resource settings". It makes a whole lot of sense to supply more LOD, such that users with lower performance computers still can have a decent look&feel. While users with high performing computers might want to set their RenderVolumeLODFactor (or object quality in the graphics setings) to a high value and thus not even see any LOD changes at all... Just to get me right, i am talking about optimized meshes and not meshes that need to be optimized, when I am talking about changed to the LODs in the way I am suggesting them. I think for users that didn't took into the LOD related issue that comes with meshes it can be kinda confusing cause they might mistake the way LODs are handled by designers for meshes are not how or why sculpt LODs were used and introduced. For example if you build a house on one side of the sim you don't have to show all the house at once but just its front and only once the user is close enough that he expected to see everything you go to the full house mesh.

Gaia Clary wrote: I think (if i understood all your points correctly), that SH-2211 covers most of what you propose: Yep. As I mentioned it with this thread I just wanna gather some feedback about LOD usage in general and if the mesh streaming could be optimized in some ways. Regarding rendering of objects with only one (high) LOD: As far as i understand occluded objects will NOT be rendered. So if your furniture is inside a house, and your camera is outside (and you are not looking into the room through a window) then your furniture will NOT be rendered and does not add to the rendering amount in your computer. My concern is not the rendering cost, but the streaming costs. As far as I understood it as soon as clients are within theoretical drawing distance and face it the assets they will be streamed for precaching purposes anyway. As for the furniture example and the jira you mentioned this can be circumvented by adding a lowpolymesh "template" that is enough to store all the needed materials to just ease up the PE, but nonetheless those "templates" will be streamed and displayed (when not occluded) without an actually need for it. It would be much smarter to just block the display of those "template" LODs when the creator or the builder already knows they only need given drawing range. This doesn't have to be done in the importer but a checkbox like "force LOD but sacrifice display distance" somewhere in the build menu would be nice. So builders could decide themselves whether they want such a feature or not, just to help them controlling their costs in a more flexible way. Drongle McMahon wrote: You might also find CTS-631 interesting in this context. Must have missed that one, watched @Made: I do get your point but really I talking about optimization. Slicing the corner of a lowpoly just to make it look a lil bit more round at close range, isn't noticable. But more important this is about giving us but formost the builders that gotta use the assets and deal with the PE some more flexible control over the usage of LODs warehousefifteendesigns wrote: I liked your idea of choosing from which draw distance different LODs appear, and also it could be a feature that the individual creator can choose how many LODs their object has (minimum 2, though). They'd have to use initiative, but any experienced mesher would probably have this And unexperiences meshers could refer to perhaps a wiki article or something written on the subject, stating which number of LODs would be required for different types of meshes. A car may require 3 or 4 LODs for maximum performance, whereas a simple table could possibly only require 2. Yeah normally game engines got other ways to deal with the optimization of how and even when LODs appear, but they don't have to deal with streaming costs most of the time since everything is pretty much precached. We pretty much stuck with a fix LOD system and I don't realy like that idea.  

Now that the first creators that didn't take part in the beta testing got their hands on the mesh project and started to work with what LL has been working on for so long, I would like to take the chance to gather some feedback on the LOD system in a more general way. As I think some finetuning and a lil brainstorming might help to ease the streaming costs some more now that we the creators and LL finally got hands on some more valuable numbers of assets and can start to evaluate them in a more realistic environment than sandbox testing. First of all I do wanna speak about the LOD switches in general. I do think that LL stayed with the 4 LOD switches ist pretty much a tribute to the sculpt history they came from, prims that need to be high poly for their cutting ability as well as parts of SL being an open world environment in general. With the sculpts mainly focused on rather organic shapes as their general purpose at first to go with 4 LOD levels was for sure the right way to go. As well as it was for the Prims. The question is if the 4 LOD level approach is still the right one for meshes or if there would be a way to find another way, that would ease up the streaming costs and to a certain degree the render costs. Let me start with some arguments of mine and finish with an idea regarding LODs that might not be that hard to be implemented in the existing mesh upload and display process. Pretty much every designer that is used to do 3D models and focuses on static geometry starts with a lowpoly model, does the UV layout and uprezes the polycount where he finds it appropriate and it is needed to support the mesh at a closer distance. Only in some really rare cases a designer even thinks about doing another midpoly mesh, not to speak about a 4th LOD, cause of the extra work it would need as well as the overall texture blurring that comes with to many LOD levels. Speaking about static geometry in general there hardly is any noticeable difference for the eye beyond the 64m range between a lowpoly and a highpoly mesh, that couldn't be compensated by the texture. Which is somewhat different for organic and especially rigged models. Given the weighting of rigged meshes most just stick with 1 LOD and well one of the main purposes if not the main for rigged meshes will be avatars, or avatar attachments and from the designer point of view at least I want them to be highpoly all the time just to support the overall renderscene eyecandy. Sure LL is still missing normal or bumpmaping to support lowpoly models but I think this kind of feature is something that we might see in the future. Given what just has been said, leaves me with the general idea that there hardly will be any use of 4 different LOD levels by designers. Yet the model importer makes people think it actually would be a good idea to do so. To leave especially unexperience users with that impression isn't a really smart idea. We all know that the LOD generator is by far away from producing any good results at all. This and the simple fact that using 4 LODs just pushes the streaming as well as render costs in a way that is hardly really needed, given my statements above. Some might argue, wait but I wand still take advantage of all the 4 LODs to ease up my cost. There is nothing wrong with it at all! Actually every designer that takes the extra time it needs to support 4 LOD meshes should get this advantage just to value their hard work. But thats not the direction I am looking at. I see the customers in first place and how a lil change in the way LODs are used and streamed might help them. Let me give you a lil example. Furniture for example quite highres when a designer wants to do achieve a lot of detail and some might just wanna do one LOD to get the most out of the UV layout and their textures. Furniture being placed in house environments it comes natural that in most cases it has a very limited drawing distance. Especially for this kind of assets the importer doesn't really reflect the use of the asset given its expected drawing range and environment use. So far if you wanna use such an asset you only support a high poly mesh but none of the lower LODs. Which works and I really don't care about the upload costs but what the real problem is that with doing it this way, you also force the object to be rendered almost all across the sim, when there is just no need for it, given its very limited drawing distance. Which initially causes very high streaming costs that aren't really needed. Lemme come to some kind of conclusion and a feature request idea, as I am not really sure if it might be planed already (might be as there at least is the models representation dropdown, but so far it doesn't seem to make any difference at all). In general to expect 4 LODs for meshes is the wrong way of thinking about them and inexperienced users shouldn't be tought nor shown that it would be a good one because it will just cause higher streaming cost than normal. As a creator I would like to have the ability to actually pinpoint the LOD to a fixed level that matches the expected drawing distance of my asset as well as to block the usage of LODs and that reflects the streaming and overall rendering costs in a much more appropriate way than it is been done so far. Of course such a "sacrifice" would be expected to have a PE bonus, especially when limiting the drawing distance by blocking higher LOD levels to be streamed. It doesn't really have to be while uploading, but some kind of extra dropdown menu or checkboxes that allow the builders to pinpoint the used assets LOD to reflect its environmental usage would be really nice and when chosen wisely something everyone could benefit from.

You got me there Drongle, to be honest made a chart for that and did detailed tests on that. Hardly to imagine someone that is interested in eyecandy would sacrifice renderVolumeLODFactor for max drawing distance *chuckles* Good to know anyway. (Not to highjack the thread I am going to start another thread as there is something that still bothers me about the LODs and I wanted to discuss it in a more general way to get some feedback from you guys.)

The automatic weighting for sure is a good start if you are not used to painting weight maps on your own by now. So you are fine with that. While uploading the mesh did you make sure to check the "Skin weight" checkbox in the Modifiers tab of the Upload Model window?

Kolor Fall wrote: Thanks for the trolling steam ... as i have repeated multiple times, I have physics turned off on my object, thus that equation should not apply. *chuckles* If you think I am trolling you just stop reading and check your resources and workflows on your own rather than making statements that are just wrong. Initially i wasn't even replying to your post but to the entire physics part of the thread. My point stays valid, the PE algorithm is fine as it is. To focus a lil bit more on your problem and what helium said: Helium Loon wrote: However, the argument breaks down, since that isn't exactly how they calculate it. A simple 4-triangle mesh, scaled up, will easily go way beyond the cost of the top-level LOD cost at a smaller level. Why? It makes no sense, since the rendering cost would never change anyway......it is either rendered or not, no LOD changes affect it. This is how the PE should be calculated for scaled objects. First of all the statement about a the tetrahedron is false. Just do the test your own. There is no difference in the PE for a 0.01³ tetrahedron and a 64³ tetrahedron. Both have the exact same render costs of 269 as well as the same PE which is rounded up to 1. What he is missing is the streaming costs that come with the LOD levels. Meshes that make improper use of the LOD get a penalty which is scale dependent. If you already know that your mesh is so huge that you by no chance need any other LOD than the highest just use a low triangle mesh for all the lower LODs thats enough to show all materials you have to apply, cause no one will ever see another LOD than the highest. Same goes the other way around. If you got a mesh that only can be seen when you enter a room make sure the highest LODs match each other for whatever breakdown you need till you finally hit the expected drawing range, so you don't get the penalty cause you don't force the streaming of unneeded LODs. Lil example. Both meshes are the same, they right one just makes proper use of the LODs for its expected scale and drawing range the wrong one obviously not (Right: PE 7, RC 869; Wrong: PE 335, RC 28209; Tetra: PE 1, RC 269; Client Version: Second Life 3.0.3 (239596)) Its not LLs fault that people miss the idea behind the entire LODs, as its not their fault that creators miss to use them for their advantage. Don't force the streaming of what doesn't have to be streamed, its as simple as this. Either art sim or not, creators will always run into issues if they just ignore the tools LL has given them to optimize the costs.