Maniac Choche

Hmm the only difference between both files is in the scale of the boxes/phys planes. Try scaling all down and resetting the xforms. Other than that .. mystery

Did you clicked "Analyze" and set it to Prim ? Mine are blue. I will quote Drongle here: “I don’t know the actual numbers, but the color indicates the magnitude of the physics weight, that is the strain it puts on the physics engine. Blue is nice and simple, going from green to yellow to orange to red as the weight becomes excessive. It shows you that the default convex hull is smaller than it should be!”

Hello, There is no need those two planes to be separate meshes. Attach them together and all will be okay. One box <-> one phys shape. https://dl.dropbox.com/u/62119361/box%20party.rar (created in Max) Regards

I like the idea too. Limiting by PE can be tricky because this number is linked to the object size, scripts, physics etc. Attachments can be limited by Streaming cost, and because of the ability to have multiple attachments on a single point , this number must be even less than 256.

So I was able to increase my teapot linkset to 9.3Mil tris. (yay). I've set my RenderVolumeLODFactor to 0.00 and was able to attach it 20 times ( just for test ) on the same attachment point - right hand. The resulted tris count should be 186Mil. When I made my RenderVolumeLODFactor back to 4 and tried to zoom , I crashed on 20Mil tris. So I can walk around with this "bomb" with my LOD factor set to 0, and anyone who is stupid enough to zoom at me is down.. This will be great for jumping out of a cake and crashing all guests

Haha yea, I've made the test on an empty sim Still, I see no reason for designers to make optimized meshes for attachments. I always thought lindens are trying to make new users to stay, but how to explain to a newbie that he/she is lagged like hell because the freebie he/she is wearing is 2Mil tris... Attachment limits need to be placed. This will force designers to make better and more optimized meshes.

Hello, Now I know there are no limits with attachments but this is insane.. http://imageshack.us/photo/my-images/836/snapshot001i.jpg/ The PE of those rezzed is ~11K. I've noticed that some of the teapots disapear when I zoom-in, so I assume some sort of render limits kicks-in. But Show Render Info still shows 7840K tris. So I'm walking around streaming vertex positions for 11K PE....

Holy cow, it's fixed ) Great job, thanks!!

I'm having the same problem with one of my test objects. Here is the Jira: https://jira.secondlife.com/browse/CTS-707? Problem is still present with the latest viewer build. Best regards

Actually there is no need for support inside your 3d software of choice. It's cool to have one to be able to see the result in real-time, but the method only interprets the data that is already inside the COLLADA in a different way ( current is linear ). That why the implementation should be easy ( *guessing here* ), because the changes will be only inside the SL Viewer's vertex shaders. Because of the more complex calculations this can slow down the rendering a bit, but in comparison to the other available methods ( log-matrix and spherical blending ) this one is really fast. The current practical fix for "candy wrapping" problem is to add extra bones ( twist bones ) to the skeleton. This can't be achieved in SL at this point. So dual quaternions can be a cheap way to avoid those problems and it can be available only to users on Ultra graphic settings, for example.

I've already created a Jira about it. According to the papers the implementation is very simple and only on a shader level. Most of the leading 3D packages already have plugins to support it. https://jira.secondlife.com/browse/CTS-724 Share your thoughts :)

Provide more info. Viewer version , 3d soft used , cube resolution etc , or people will start guessing Best regards

Hello, One other choice is to provide demos of your products. Demo textures, no mod with resize script. Mesh objects are much more difficult to steal and even if the thief is successful he/she needs to have "payment info on file" in order to reupload the model and to pay for it. So providing demos will be much more safer. Best regards

Okay my uploading tests (same steps like in your second comment on SH-2045): Five attempts: 1. 3.196 2. 3.196 3. 3.167 4. 3.595 5. 3.869 There is definitely something wrong .. Best regards

I see the exact same numbers in Mesh City ( like in your object descriptions). Didn't tested the upload, yet.