Dain Shan

I did a quick peek into the OpenGL specification. And it seems the normal dirction is based on a vertex calculation instead of the surface calculation. That would explain some concerns about too many vertices. There are 2 sources i peeked in http://www.opengl.org/wiki/Calculating_a_Surface_Normal And for the lights http://www.lighthouse3d.com/opengl/terrain/index.php3?normals Seems we have to be very careful in regard of joining verts, to be sure we get the proper calculations. As far as i can see it is really important in regard to smooth shading.

Ah Yes that would be another explanation. Thanks

Runitai Linden wrote: THIS is exactly the kind of feedback I'm looking for. Something isn't adding up here, so I took a look, and this is what I found out. Not all triangles are equal -- the streaming cost assumes an average of 10 bytes per triangle, but on low poly or faceted objects, many vertices are used in only one triangle, so the average triangle size (in bytes) for those objects is often much more than 10 bytes, not to mention the overhead of the mesh header and LLSD tags, which can outweigh the size of a tiny mesh. It's fair to charge more for these for a few reasons: 1. The extra data has to be streamed, creating overhead. 2. An extra HTTP request must be made for a tiny amount of data, creating overhead. 3. Actual render time performance of these objects is worse per triangle due to a high number of post TnL cache misses. #3 will vary from machine to machine, and will be much more noticeable on low end machines. As for 1 and 2, this could cut both ways -- using one small mesh multiple times will load better and require less bandwidth than baking multiple instances of that same mesh into one big mesh. The streaming cost already ignores the header when determining cost, and the overhead of the LLSD tags is constant, so a deduction could be made there. As for the extra HTTP request, that's a protocol issue builders have no control over, so it's really not fair to have that cost against you, and future protocol improvements could theoretically stream multiple meshes with one HTTP request. Thanks for the example! I'll need to see some large mesh builds to get a better idea of actual bandwidth usage and file sizes, but in the future we'll probably start talking about a visible mesh data size budget instead of a visible mesh triangle budget. Glad to be helpful. Im still trying to hammer some of your points in my head. Especially the line: "Not all triangles are equal -- the streaming cost assumes an average of 10 bytes per triangle, but on low poly or faceted objects, many vertices are used in only one triangle, so the average triangle size (in bytes) for those objects is often much more than 10 bytes, not to mention the overhead of the mesh header and LLSD tags, which can outweigh the size of a tiny mesh. It's fair to charge more for these for a few reasons:" Im a bit baffled. How can a triangle have more then 3 vertices? By the definition of an triangle, thats simply not possible? Only explanation i could come up with is creating an irregular mesh, where one corner of a plygon sits somewhere on an edge of an adjacting triangle. But still then .. this Vertice has nothing to do with this triangle at all ? Other thing would be an Subdivide of an edge. But even then the uploader would change that subdivide into another additional triangle. Maybe you can explain a bit further what is meant here ? Dain As always, im sorry about my bad english ...

Voted on ... It would clear some important issues

Alright .. Theoretical example.. A cube standard Prim 120 triangles. Copied 14999 times. That's 15000 x 120 triangles = 1800000 Triangles as a whole Mesh cube 2 triangles per side = 12 triangles copied 14999 times That's 15000x12 triangles = 180000 triangles Even if all cubes are in the visibility range, and even if that is a highest LOD, you are far below you 200000 limit. We stretch that out a bit. We bit a BIG quadrate with this 15000 Cubes side by side So we have as we can say roughly a side builded from ( i round up here ) 123 cubes That side would have an lenth of 123x0.5m so 61,5 meters. Places in the middle of the sim and assuming a view angle of 90 degrees (far Higher then the actual view angle is ) we can assume that you see about 50% of this cubes. That means also we can see cubes in a distance up to ( since we only see 50% of them ) to 61,5 / 2 = 30,75 meters. LOD in High is as mentioned before Diameter of the mesh x2 in meters. Means every cube up to 1 meter away from us is in High LOD. ( If i count that right? ) rest in middle or even low LOD. For the sake of an Argument lets take the absolute possible worst case .. All of them are in HIGH LOD ( Impossible i know, but just lets assume ) So .. with all this bad and far too high numers we see 15000 / 2 cubes with 12 triangles each. That 7500 x 12 = 90000 Triangles .. not even half of the limit 200000

Thanks i diddnt noticed that. That may explain this behavior

Hi there Many thanks for the explanation. Any input is very welcome and needed. However, i still have a hard time to wrap my brain around the concept. Essentially you say here that the creators of Meshes have to deal with more restrictions in regard to resources then the average prim or sculpt user. For the sake of better overall performance? That sounds .. odd. Forgive me for being blunt here but that calculation will NOT work. Essential we already know that the majority of People out there don't give a damn about resources other then prim count. Its the only measure they have right in front of their eyes. They don't care about KTris drawn or Polygons on screen. They don't care if a sculpt has 10 times the polygoncount .. as long as it looks good and only has one prim against the parcel count. We stated this over and over and it is tiresome to see yet again a comment, that we should forget about the prim equivalent. It simply not true, in the end it will be all that matters. How many prims will that mesh take from my parcel or sim allowance. That's all. As you might already have see, most of the mesh creators out here are already building with the resource count in mind. Means they optimize their stuff to a great extend. But the restrictions are still set in a way that we can't understand, especially if they make no sense whatsoever. You gave a very nice example here. 1/15000 of a sim, so that IS exactly 1 prim till now. ( We leave that sculpt debacle off the side here ) Ok lets see we have an empty sim, and 1 rezzed standard cube. As you probably already read here: http://community.secondlife.com/t5/Mesh/Linden-Magic-Math/td-p/921425 It is totally not understandable why a mesh with 1/10 the resources of a simple cube ( Yeah right only 10% of an ordinary cube ) costs twice as much as the the cube in regard to the prim equivalent. You can expand this. There are even more builds out there who have much less triangles then their prim counterpart, so essentially were helping you already with the performance. We make things that costs far less resources then even the standard original Linden prims. Why the restrictions that punish the mesh creators ? Even more so that, if we stop making meshes and flood the world with sculpts instead, you would get a far bigger impact to the negative side of things. There are still a few points in regard to meshes that still need a good overhaul. But thats another story and has nothing to do with ressource costs.

Good morning. May it be that they changed something yet again? This morning i reuploaded some of my models in Sandbox 20 again. I noticed that the Prim Costs and the streaming costs dropped significant to the value of last week again. So a modell that had a streaming cost of 3.3 yesterday in sandbox 20 now has a streaming cost of 1.8 !! No changes in the uploaded files, they are the same as yesterday. Interesting .. if i rezz the Mesh from yesterday it still says streaming cost is 3.3 Seams the server version is the same Mesh Experimental 11.06.09.232605

I dont know But everyone who try to build a house and straight structures and clean Arcs with a sculpty is welcome to show me. And i still can do that with FAR less polygons then with a sculpt. http://i54.tinypic.com/maxmaa.png http://i55.tinypic.com/fqvt0.png http://i55.tinypic.com/2je1jea.png 2 Prims as cost for that .. 570 Polygons ...And seeable and hold form in the far off LOD Not to mention the different textures on the object sides that can be replaced any time. And even better, a physics that allow to walk right in the short tunnel. Till now , if they dosent tweak the Ploygon to Prim Ratio up, ill take the mesh every time. Im not sure, but i think even with normal Prims ( that would take at least 4 or 5 ) i would have more polygons. ( i could be very wrong here ) AND before i sound too ballsy .. im just a beginner in creating that stuff. Im absolutely 100% sure that there are many people out there, who can do it even better by a far margin.

Many thanks I start to analyze the files ASAP when im at home ( and to whoever downloaded the file already, thanks to make me wait for 60 minutes till i can download it also )

Well maybe we can work something out here. Eveline would you be so kind and do the following. Make just a single cube in Sketchup 8,2m wide and texture all 6 sideswith different textures and export it as a collada file. Then open the collada file and copy the whole text into a post here? Feel also free to mail it to me if youre not comfortable with this. I want to make a direct comparsion between the different files. Im not bad with that ruby stuff that is the script language of Sketchup, maybe i can come up with an export filter if i can compare the two and see what wend wrong.

Well i did again abit o research on the Export matter I found the following entry on the Homepage of Collada Source https://collada.org/mediawiki/index.php/SketchUp It says Google SketchUp is a product that supports COLLADA. Exporting to Collada DAE files is officially supported in the Pro version. There is a possible workaround from the free version. The workaround is exporting to Google Earth (*.kmz) and then renaming the .kmz to .zip. When you unzip the file the "model" folder contains a DAE file of your model.  This leads me to the assumption that the real export only works with the pro version. The workaround is mainly a way to rip the google earth format apart. And i doubt they will look into that one. Maybe someone here has a pro version and can tell if a exported file looks different from an file made with the workaround?

It is the Exporter of Sketchup It produces unusual results sometimes. Its really a shame, because it would be a the right tool for en entrance to Mesh. Well that being said, Sketchup 7 does work as long as the modell dosent become too complex. Really important is, that you always use only ONE piece of geometry that you then extrude or deform. If you add geometry ( say 2 cubes instead working with one) you will end up with submeshes that you probably dosent want.