Gaia Clary

i disagree in two ways: I think that the wast majority of objects is in the range from 1 cm to 10 meters. So i consider bigger objects as ... big. despite that you now CAN have objects of sizes up to 64 meters (bbox wise). In my tests with objects up to about 2 meters i can get my objects into the same range of PE regardless whether they are made out of meshes or sculpties or prims. this is true as long as the objects contain more than 2 prims. And the more prims they actually contain the better mesh performs. So (as vivienne daguerre has shown on another thread) even houses (which are certainly big objects...)can become cheaper when meshes are used. For me using meshes (in the given range of size) gives me following benefits I have much more control over modelling. So i can mold my prims to my needs and can potentially do high optimizations. I have much more control over texturing. I have 8 times more texturable faces, so i can do much more detailed texturing. Because i can split up my textures into up to 8 individual images per prim, i can make versatile use of tiled textures and such i can reduce the amount of needed texture data enormously. I have immediate control over physics. No longer do i need to add invisble prims and set my object to phantom. This works well as long as i provide an easy basic physics shape. I have full control over LOD. I can do high optimizations especially for lowest LOD, which makes a big difference for objects in the examined range (1cm - 10 meters) The backdraws with meshes (true for any size) for me are: It takes me a lot of more work to define the LOD meshes I have significant more work to keep the unwraps of the LOD meshes intact. I do not use decimate, but i make LOD optimizations by hand. This is the only way by which i can get acceptable LOD behaviour (well i am very picky here) Changes on ready made Objects are painfull because of the changes i have to propagate into the unwraps. Texturing work raises up significantly. Taking upload fee aside for a moment, i am starting to get confident that meshes can compete well with sculpties as long as high quality visual appearance is of concern (and as long as we talk about the given range of size). So wherever you want something to look realy nice, meshes look like they are very competitive. For Low prim/low budget work sculpties will still win.

Have you tried to set the physics type to none for all elements which do not seriously add to physics behaviour ? I could imagine that for a boat to work appropriately in SL its physics shape could be a simple brick ? That should bring physics cost down to near zero... Well, i must admit that i never played with vehicles, so i may be entirely wrong.

Ayako Kaligawa wrote: Vielleicht wäre es angebacht diese Tauglichkeitsprüfung auch in anderen Sprachen anzubieten! J'espère bien! Ce n'est que justice. :matte-motes-bashful-cute:

Drongle McMahon wrote: So then I tried to see how that order was controlled in Blender. I couldn't solve that. That means that we need some sort of convention to order the objects included in an upload ? Would it be feasible to simply use the object names to sort them in alphabetical order for example ? Maybe a name convention could be used like this: braceteat_lod3 braceteat_lod2 braceteat_lod1 braceteat_lod0 braceteat_phys ... blade_lod1 blade_lod0 blade_phys This convention would allow me to keep my different LOD versions in one file. And this name convention won't break the alphabetical order in the 4 lod files: So in the high LOD file i have the objects: blade_lod3 braceteat_lod3 guard_lod3 handle_lod3 and for the medium LOD file i have: blade_lod2 braceteat_lod2 guard_lod2 handle_lod2 and in the physics file i would have: blade_phys braceteat_phys guard_phys handle_phys This means that we have to take care that the name conventions are kept intact in our own editor (which would make sense anyways). If Linden Labs can not solve (or does not want to solve) this problem, then i can imagine that we are able to provide a simple tool which could be based on such a name convention. This tool could reorder the Collada file so that the importer now imports correcly. Does that make sense ? If LL states they will not provide a solution for a multi part import other than what they have now, then i would immediately start working on such a tool and i guess i would try to make it tool independent, maybe even web based ;-) Drongle McMahon wrote: Meahwhile, you drew my attention to the upload fee - so I uploaded 64 spheres for L$221, when they cost L$151 each on their own, and that's even if they are all different. The data requirements must be exactly the same whether I upload them all and unlink them or upload them individually, but they are going to charge me L$221 for the first and L$9664 for the second, 43 times as much! That is completely ridiculous. Maybe we should realy keep on creating jiras, especially when looking at the close statement of CTS-691: Charlar Linden added a comment - 12/Jul/11 11:34 AM Other upload methods (texture/image/sculptie map) do not take into account overhead associated with the file. The more complex the file, the more it costs. Please note: We're still tweaking these calcs prior to mesh release and welcome the feedback.

TANAKAAKIO Inshan wrote: There is a lack of balance. I think upload fees should be reviewed. It seems that uploads in one chunk often brew up unexpected results, so is not recommended for mesh geometries at present. However, if uploaded individually, fees come at a price and we must assemble complex meshes by hand painstakingly in world. The related Jira to exactly this question has been closed. Mabe we should reopen a new jira for that ? I am not sure if comments on closed jiras are read at all by LL ...

Drongle, i think you have put me on the right track ;-) I remember that i originally had 5 objects. Later i joined 2 of them into one single object. And it appears to me that this may explain very well, what causes the problem... I will take a look at the dae files now. thanks for the hint !!!

yes, the previewer shows what i actually get when i upload the sword in one chunk. So the problem may be located in the DAE. I want to check if i made a mistake before i add a jira for it. What i do during exporting was: for each LOD i selected the 4 parts in the exact same order (starting from top to bottom), then exported the selection as Collada-1.4 (i used Blender 2.49b for that)

Hi. I have an object here which is made of 4 parts: Braceteat (at the top) (using 3 materials)Handle(dark redish polished wood) (using 2 materials)The guard (using 2 materials)The Blade (using 1 material)I made it of 4 parts because i want to provide a few different blades, some different guards, handles, and top decorations for creating many different looks which can be combined in world. The good news is: Its PE is 4 when linked to a linkset. So it is equal in costs compared to a sculpted prim object (made of 4 sculpties) Each of the 4 parts has got 4 different LOD meshes (high to low going from left to right: Now i want to upload this sword in one chunk (uploading the 4 parts one by one costs about 650 L$). But when i try to do that, I face one big problem with the associations of the LOD-meshes to the high LOD mesh: Look how the 4 LODS are shown in the previewer: You can see that the braceteat (the coin at the top of the handle) and the guard get exchanged on LOD2 and remain exchanged. Furthermore the handle on LOD2 and LOD0 looks like a cylinder, while it should be more like a coil (as seen in LOD3 and LOD1). the only part which looks right to me is the blade. How can the wrong association of the submeshes to their LOD be explained ? How can that be avoided ? How can the distortion of the handle be explained ? To be clear: I have uploaded all 4 parts of the sword one by one and the LOD behaviour for all 4 parts is correct and no distortions can be seen apart from what is expected due to LOD.

PE just starts to get into more reasonable range, at least for medium sized objects ( smaller than 10 meters). In that size range i am able to get very close to the costs (PE wise) compared with builds made out of Sculpted prims (as long as i compare a build made of 3 Sculpties or more with an equivalent mesh build).

I made a Jira for it. Maybe it is read by some lindens. maybe we get some explanation for why it is like it is. You may want to comment on https://jira.secondlife.com/browse/CTS-691

I can not say what actually makes LL set the costs as they do. The only reason i can see for this move is to avoid getting large Mesh objects into SL for now. I do not know why this is so. I do not know if it will ever be changed. IMHO it makes no sense to compare Sculpties with meshes to understand LL's decision, even if all numbers indicate that meshes are the better option. LL would be quite insane if they would discourage the usage of the "better tecnology" in the long term... Its just a pity that they do not tell us the whole story (with simple to understand words) ;-(

The longer i think about it the more it appears to me that the "punishment of mesh" indeed could be a way to keep people from swamping the grid with non optimized mesh objects. As far as i can tell from the last few months many (many!) people just do not know exactly how to get along with Mesh-development and especially with optimizations. So the current cost settings seem to keep most people from working with meshes. Just a few enthusiasts might want to pay the high bills. Maybe the cost system makes people learn optimization strategies to actually get mesh objects cheaper (e.g. my kettle quest is mainly developed because i wanted to learn how to get out the most for the least possible costs) And punishing larger objects in first place may be even a wise idea, so we all can learn in the small scale before we can go to the big builds... Well this is just my 2 cents here trying to get some sense out of the current costs settings. It still does not make any sense to me to put such a high upload fee to meshes. that is just too much, especially because the only way to check if something is working as expected in the environment where it shall be used is by uploading it. So if LL would allow temporary meshes, the situation would be a bit more comfortable. But Actually my proposal is to "Make it easy": 10 L$ for each mesh in an upload 10 L$ for each added texture, so mostly 90 L$ per prim (assuming it can have up to 8 textures) All the rest most probably will sort out itself. I.e. We won't want to rezz high Poly meshes due to PE. So what is the issue ???

Constance Flux wrote: Sculpties are causing lag. Economical, optimized mesh modeling can be 10 times more efficient than the equivelant sculpties. Sculpties almost always have tons of tri polys that are not being used efficiently. Death to the lag monster sculpties. It's only the current bizarre and inflated mesh PEs that are giving the impression that mesh is inefficient. If prims and sculpties were better every 3D games company on the planet would be using them. Death to the sculpty:matte-motes-evil: Have you taken into account , that the smallest supported sculpty only has 16 faces ? Have you taken into account that collapsed vertices are removed from the triangle set before the sculpty is actually rendered so collapsed triangles effectively count nothing ? (almost...) Have you taken into account that a whole lot of information used by sculpties actually never needs to be passed around, because it is generic ? Before you conclude now, that i must be a sculpty fanatic, i'd like to tell that i am realy doing my best to show how to get over the artificially introduced barriers set up by LL. It would be sad to see mesh failing, just because most people "think" its too expensive (due to heavy PE and minimum upload fees of 150 L$), where there are certainly tons of reasonable cases where mesh can be the better option (also in terms of primcost), and not only with avatar attachments... But always remind that "The condemned live longer ..." :matte-motes-evil-invert:

Ashasekayi Ra wrote: The billboard method can be great for PE. But, if you need to use one with alpha (which is usually the case), you will have to deal with the alpha flickering bug showing up on all the LODs. And, "shiny" won't work with the object any longer because the mesh has a texture with alpha on it. You can avoid this by using a separate material for the billboard (If your object has one spare material). Then alpha flickering and the backdraw of having no shiny only affects the billboard LOD. Also when you only need one image as Billboard (and do not use crossed planes like with trees for example) then there is no Alpha flickering at all. When you have multiple crossing images for the Billboard, then maybe we can use some clever UV-layout trick (like we can do for Sculpties to avoid flicker)...

I would expect that the importer did tell something like: "Too many texture faces: 9 used, 8 allowed" "Too many physics vertices: 450 used, 250 allowed" "Too few texture faces in medium LOD: 5 used, but 7 needed (see highest LOD)" "Unweighted vertices: 7 in mHipRight" "Bones missing: mHipLeft, mAnkleRight" "Bones unknown: m_hip_left, m_ankle_right" And so on... That would be the simplest and most straight forward "documentation". And IMHO even the most efficient way to document. From my experiences with Primstar i have the impression that most users seem to either not find the docs (my fault :matte-motes-agape: ) or don't read them (their fault :matte-motes-grin: )

ah, then this happens when you use the automatic generated LODs... and the results depend on the set of imported objects. Well that would make some sense. I have given up on automatic generated LOD a while ago since i realised that making my own LOD's is much better and helps me a lot to reduce PE ;-) So if i use my own LOD-meshes then the PE should not change between uploading them separately or all at once... BTW the best trick i learned so far (from a feddback on my kettle request article) was to use billborard-like mesh for the lowest LOD. For my kettle this helped to bring streaming cost realy down below 2 and still have a very good look from the distance.

Do you say, that one and the same object can have different PE depending on how it was uploaded ?

Medhue Simoni wrote: What will bring more people are better full sim builds, more interactive environments, more fun stuff. If you ask me, all the limits put on mesh is completely counter productive. Are you realy sure about that ? Has anybody ever tested, how a complete environment import would be charged ? Has anybody ever even tried a full environment import ? And applied all possible optimization methods to the included meshes ? To see how far we could get ? e.g. split a huge tree into several (reusable..) parts to reduce render costs ? create linksets and set children's physics to none where applicable... etc... I have not done this. I even have no idea how to organize such an environment upload. Just thinking about recreating the different LOD's for the environment makes me anxious about the overall effort behind such a project. So maybe talking about full sim uploads is just not a practical method... But if it where the way how we should do Sim development with meshes... then it would be interesting to see if we could get away with that approach...

Monti Messmer wrote: If the primcount stay this high meshes are even useless for clothes because then Sim-Owners won´t allow you to come because of the high rendercost your avata has. Allready have this with some peoples hair and boots and .... This somehow implies that rendercosts would go down when LL would decide to lower PE ;-) Of course this is not true, but ... As far as i can tell, even high PE meshes can be much less resource taking than comparable Sculpty/Prim builds with much less PE. So an avatar who wears mesh clothes may in fact use significantly less resources although it wears significantly more Prims compared to an equal looking sculpty clothes set... What i do not at all understand is the reasoning about upload fees and PE. Well, we can talk as much as we want, but it appears to me that we better should find out: How does LL want us to use meshes Where does LL want us to use meshes Why does LL want us to use meshes. If we know that (and currently we are just deducing from what we see and guessing and believing), then we can ask: How does LL's intention relate to LL's pricing ? Maybe answering these questions can shed some light on what is going on here ;-) But i am afraid that we are supposed to swim in unknown waters and find our own pathes through it. And LL probably will have to check if their pricing does realy get us where they want us to go.

Maybe this list of observations can help to lower the PE : http://blog.machinimatrix.org/2011/07/08/quick-guide-for-mesh-cost/ I just created this article from a post i made earlier today in another thread on this forum. I might also add some visual examples later.

Vivienne Schell wrote: I did not crticise Drongle for THIS (btw, did he ever upload his museum - or parts of it - on the mesh beta?). I am talking about Mesh beta... So the museum is part of it. You can find a very short preview on the Mesh Wiki page (the last 20 seconds of the video shows a few imressions of it)

Vivienne Schell wrote: Wrong is that it´s Drongle who claims that the "high" PE and whatever will prevent Max from rebuilding this in mesh. If it were Max expressing his wish to rebuild this in mesh at all and complain I´d have no problem with it. But couldn't you (anybody) use Max's build for explaining what would happen to anybody who attempts to create such a full environment based on meshes? Using a practical example to explain a general problem seems legal to me. Vivienne Schell wrote: Isn´t the mesh beta open for a while now (Almost two years, closed beta included?) Didn´t you all have enough time to build and upload a full sim in mesh for *no* upload fees to give an example?.If you did not, please explain why not. Because it is a Beta which gets scratched very often. Meshes have to be reuploaded all the time, Regions have to be rebuilt all the time, Most regions are sandboxes with return in 48 hours... BTW have you ever seen the museum built by drongle ? That counts for me already as an environment (although not a full sim) . But i think that Drongle might be one of those who actually have practical experiences in working with whole mesh environments...

Vivienne Schell wrote: Drongle, better let the creator speak for himself. Using someone else´s work for your biased cause is fishy. I am confused. Is there anything wrong with using examples from others to express ones ideas and thoughts ? And as there is only positive feedback towards the creator in Drongle's post, i can not see exactly what you are criticising exactly. Can you explain in which way Drongle is biased ? Honestly i can not see it, maybe because i myself am also biased..., But maybe you can show where the argumentation is wrong ?

Drongle McMahon wrote: the dashed vertical lines are at the radii 5.43, 10.86 and 43.44. I do not get exactly how to match the radii with the maximum BBoxes as you wrote in your previous post: e.g. for a cube of 15,15,15, the radius should be sqrt(x*x + y*y +z*z) (with x=y=z=7.5) . So i get: sqrt(3* 7.5 * 7.5 ) = sqrt( 3 * 56.25) = 12.99 But you write that the radius of that BBOx is 10.86. When i make the reverse calculation, then i get a bbox of ~ <12.5,12.5,12.5> to match with a radius of 10.86 (roughly) Can you explain where i am doing wrong ?

I have updated my earlier post and added your remark in detail.