Davido Chrome

Seems like I was wrong about Convex boxes, but prims should be more efficient. Now, I can't seem to get how to make a vehicle that don't sinks into every prim that is at a slight angle from it's trajectory... Getting its physics cost down to 0.4 doesn't help... There seems to be something wrong with both the info I have gathered and the way the server calculates Physics cost...

I am not sure which is best just yet. Primitives keeps the lag low. If all you want is low land impact go for Mesh. The fact that Primitive on Prim doesn't work well seems to have to do with how primitives are calculated, rather than it being less efficient. Thus, best should be to use Mesh for one and primitives for the other. I suggest roads should be prims as you often want vehicles to have more custom options for the shape to control how they interact with the terrain. Making the boxes use the convex Hull option for a road would be a bad idea, as the collision shape then would be an obblong sphere and not fit the visual representation of the box. And, according to the document I link to boxes are much more efficient than Convex hulls. And making a road from Oblong spheres would result in a rather hard road to drive on... For off road terrain though, that's a whole different ballgame. I was at What Surf and Simboard the other day, they have new waves there that seem to be made of a whole bunch of convex hulls bunched together. And they are REAL nice to ride, believe it or not.

Prim roads cause less lag as their shapes are mathematically defined. When an object meets a primitive the physics engine needs to make one calculation per collision, while a Mesh road causes the engine to make calculations for every face its physics shape has. Interesting fact, I made an elevated turn from 21 prims. By adding an extra prim with physics shape none I make the linkset use the new Land impact system. The turn is still 21 prims, but it has a land impact of 11. The same way I can make a 3-prim 64 meter straight with two prims for safety fence have a landimpact of 2 by adding a hidden prim with physics shape none. 4 Actual prims, land impact 2.

Interesting findings. Simplest primitive on simplest primitive seems to make you sink into the road/ramp/whatever. However, if either or is made from mesh or a complex primitive, all is fine and dandy. Just as long as vehicle and road isn't both simplest primitive. This means that it should be best to make the roads from prims, and custom Physics shape for the vehicles.

I edited the post and fixed some outright wrongs... Info is more reliable now. For more in depth information check out This link.

The only place left I know focused on Freestyle boarding is What surf and Simboard park. http://maps.secondlife.com/secondlife/Opelessence/36/216/1526

I would switch to Blender. There are a lot of tutorials for Blender out there, it being open source and all Blender tutorials are pretty much always free. http://www.blender.org Also, see http://blog.machinimatrix.org/ Builders Brewery also holds a variety of Blender courses.

Never buy furniture no copy. One rollback and your furniture is gone...

Simboarding is wonderful. When you gotten a hang of Simboarding, why not try Simball? See https://simboardupdate.wordpress.com/ for the locations of the last matches played. Every post has the SL-url of where the match was played. The site is updated automatically after each match, so the chance is big that people are still playing at the location of the latest played match.

SL do need a consumers right movement.

It works after having done the Mesh upload questionaire that you link to. This might be a fault in firestorm though, the link in firestorm goes to "secondlife.second" which is a dead link. The firestorm team has fixed it for the next release according to communication in the Jira. http://jira.phoenixviewer.com/browse/FIRE-4372?focusedCommentId=70552#comment-70552

I thought mesh can be used to effectively reduce physics induced lag by making vehicles with less collision surfaces and less individual objects to keep track of in a linkset while retaining the same amount of detail and that Mesh can be used to make less snaggy tracks and roads as well as vehicles that tax the simulators significantly less. But, this turns out to be wrong. For roads, simple primitive shapes are the best answer. Physics Performance Cost in order of Cheapest first Sphere Capsule - (Not available as I type this. Possibly used by avatar collision boxes. Always used by pathfinding characters.) Box Triangle (A single triangle surface on an object) Cylinder Convex Hull (Basically the prim-shape with all holes closed and with no more than 256 vertices.) Meshes (Which becomes a list of Triangles, I don't know how many surfaces you can add before it passes Cylinder and Convex Hull in cost, I suppose very few.) The mesh upload Analyze functionality performs a "convex decomposition" resulting in a collection of convex hulls which approximate the overall shape of the mesh to the specified degree of accuracy. Terrain and Mesh. Mesh terrain that uses a minimum number of the largest viable triangles (i.e., a minimally triangulated terrain--maximizing the size of the triangles involved and minimizing the number) will generally be significantly more efficient than the default terrain. Terrain made out of boxes will also be highly efficient. In both cases, be sure to flatten out the linden terrain to ensure the physics engine doesn't end up testing against both your terrain and the default terrain. Keep the terrain collision shapes simple! It doesn't have to be as complex as the visual representation. Havok is smart about mesh collisions: given a primitive shape A colliding with a mesh B, it typically only has to test for collisions between A and those triangles in B whose AABBs (axis-aligned bounding boxes) overlap with the AABB of A. This is why having a landscape with a moderate number triangles can still be very efficient so long as those triangles are fairly large and sparsely distributed (i.e., no areas where lots of little triangles are tightly packed). Accordingly, we compute the physics cost of a mesh largely based on the average size of the triangles in it. That's why shrinking a mesh makes the physics cost skyrocket: if any reasonably sized object collides with a small, dense mesh, it will likely overlap many of the mesh's triangles incurring very high computation times. Vehicles and driving surfaces Also, avoid using shapes with dimples, hollows, cuts, or any other kind of "hole" (i.e. avoid non-convex prims) on vehicles and avoid the most complex shapes like hollowed out prims and Tubes, Rings or Toruses for surfaces for vehicles. Replace toroidal wheels with cylinders (best option) or at least make them have physics shape type "Convex", etc, and keep the total number of colliding prims (prims with physics shape type other than "None") on the vehicle to a minimum. This will also reduce snagging and significantly improve performance. A simple invisible horizontal cylinder (with equal radii) placed in front of the vehicle would provide an optimal collision shield if one is still needed. (This also implies that a track with mesh turns with an optimized amount of surfaces will cause a lot less physics lag than a cut cylinder, although that is not the most effective way to go about it. The physics engine knows a prim cube when it sees it, thus using cubes is the best option. They can be stretched and resized but all gain is lost of you deform the prim in any other way. ANY other.) However, having a too simplified shape makes the vehicle sink into prims. Ground vehicles keep track of several "average collision normals" where they hit the ground and build up a history of what that collision normal is at each point where the vehicle is colliding. If they hit a momentary normal that is totally out of agreement with their history they will discard it, but they start to modify their history to accept such disagreeing normals. The idea being to discard the momentary incorrect normals encountered at prim seams at roads. The more collisions you get the more data goes into recomputing the expected normals. So it makes sense that a "less cheap" vehicle that actually has more collision points will correct faster when encountering true ramps and obstacles (as opposed to bad normals at prim seams). I like to double up the Convex Hulls in the wheels. The one slightly inside the other, this seems to give a nice balance between low physics load and enough collision data for the vehicle not to sink too much into ramps. Edit; These days I have found that Cylinders are actually the best option for wheels. Troubleshooting, vehicles. Q. Does changing the physics type only work for mesh objects? I tried changing the physics type for parts on an old Sculpted bike to none, and when I try to get on it get a Script error. "Script cannot enable physics -- physics resource cost greater than 32". A. By changing the physics shape type from "prim" you are opting in to the land impact system introduced with mesh. The objects don't become mesh objects, their land impact is simply calculated that way. The fact that after changing some of the parts to shape "none" you still have a physics resource cost >32 lets you know that you have a lot more simplification to do before it will be efficient. Try setting as many prim as possible to "none" /and/ setting the wheels to convex hull.

I have ther same issue. Could you please fix?