Beq Janus

I can talk a bit about it. People with sleep disorders have often come to me for help for that reason The SLM format is indeed proprietary and we produce the SLM from the DaE. The SLM is designed to be very lightweight and suited to streaming. The size differences can come from a number of sources, most typically they arise from people using generated LOD models. The GLOD library that is used to produce the simplified meshes has some random seed in it (for reasons I have never understood, nor really investigated) and as a result, the generated LOD models can vary a bit with each upload. This becomes worse as the models become more complex, given that you can place an entire linkset in a DaE along with all the LOD models for said linkset, the permutations become fairly horrendous. Most of us though tend to keep it simple, a DaE per LOD. @Drongle McMahon made an excellent summary of the Mesh Upload format back in the day and I referenced that extensively when I blogged a description of the work I was doing to understand that (before I was working on Firestorm) when I was writing a plugin for Blender. The SLM format is a simple hierarchical list of meshes. Each "Material face" in the Mesh sense not the SL sense is extracted as a separate mesh, thus an 8 face object is composed of 8 separate "meshes" in the upload format. Where a mesh is a self-contained list of vertices, edges and UVs. Each set of these "material meshes" is packaged as a mesh unit (effectively a mesh primitive) and an array of these (1 or more) is combined into a LOD Model. Then we have a repeat of that for each LOD Model, a decomposition block for the various physics shapes and the texture info. A hopefully better description is in my blog, though I probably understand it better now than when I wrote these (which was part of the point of writing it of course) but I think for the most part what they say still holds true. An initial waffly blog about why things are not always the same LI A more thorough walkthrough of the Mesh streaming format. The above quote related to the Axis in the mesh. In theory, it could change the LI.....in theory... When the material meshes are made they are individually compressed using an equivalent of "gzip -9". Zip compression works on repeated patterns and some data is more compressible than others. in some objects it is plausible that a mesh rotated by 90 degrees is more easily compressed. That said, it is hard to arrange that arbitrarily and it does assume that the vertex coordinates are different not just that the axis annotation in the DaE is different, as I don't think that is even used (though I have not checked...). Anyhoo, very late. Bedtime. Beq

It is not overlaying really, in the same way that local images work it would be fully part of the local scene. A mesh is an asset with a UUID, the UUID points to an underlying mesh UUID, which in turn represents the SLM compressed Mesh. The temp mesh solution would allocate a local UUID for both the asset and the underlying mesh, and construct the SLM as it does for upload today. The full physics access that the uploader has today would be available. Though I take your point that part of the problem will be the physics shape as we can at best only simulate that. As I said, a lot of things would have to be written to make this happen and the physics limitation could be addressed on the way. I also believe that an iniviewer, in-situ mesh preview with full material support has massive productivity benefits without the final step of physics production. Entirely up to them, they'd be gone next restart and they'd be living a lonely life. Might as well spin up an open sim :-) That's an option though I cannot see them (LL) going for it. Raise a Jira and propose it though you never know, I'm happy to raise it at the Content Creator UG if you can't make it and if you have a Jira I can point Vir at; that said, if you enable SLM caching (MeshImportUseSLM) in FS (which was known to cause some issues in the past, but I use it by default and don't tend to have issues, ymmv) You can quite happily upload to Aditi and then move to Agni and find the upload settings replicated. Not quite the same as transferring but a step in the right direction. Beq

There is no such feature but there is no technical limitation per se, a mesh is no different to a texture in how and where it is cached, a local mesh is entirely viable, the preview window in the uploader is after all a local mesh view, albeit very limited, making it work though, that's a whole other matter. The devil is in the detail. I have a TODO item on my personal project list for build tool improvements, to add local mesh support to Firestorm (and ultimately contributing back to the lab so everyone gets it). It is, however, a lot of work. The concept is simple enough, but because of the way that SL imports mesh there is a lot of messing around and I suspect a lot of issues. You need to manage multiple temporary models and changes to those that roll up into a single temporary mesh. some of those models are potentially auto-generated, tweaking those might cause them to break and the viewer is not necessarily able to handle that "live" at the moment. How do you get the edit tools to show the LOD Model or physics shape that you are working on etc etc. (Clue: the next release of FS has the first stab at those). Overall, getting it to work, is probably not *too* hard, but then making it usable and safe for people, in general, is a lot more work (consider things such as the bug in materials when using local textures and people that have edit rights on your stuff and how that can extend to meshes). It is one of those ideas that you think, "oh that shouldn't be too hard", then you realise why it wasn't already done as you plan out all the things that go into it :-) Small steps along the way are happening.

Are these selected objects meshes? Blender DaE Export can't export non-mesh (things like paths, lights etc). is that layer visible, I don't recall testing this myself but it would make sense that hidden layers are not exported.

All actual physics is managed on the server side. Second Life uses a 3rd party physics engine known as Havok . When a collision event occurs it is always the sim that has detected it. An example of this is when you try to drag a pot plant from your inventory onto your coffee table, where does it land? The decision happens in two stages. The viewer uses a combination of ray tracing and other functions to identify the "object" on which your item will land, hopefully, your table. The sim is sent this information and uses the physics shape to decide exactly where your dropped item sits, ideally the table top. This is one important reason why you should encourage creators to define a proper, representative physics shape. When the server side physics does not correspond well with the visual shape things go wonky As you note, the breast physics are not handled by the sim, we all do our own jiggling. Breast physics is different to game engine physics in the sense that it is a deformation, like the compression of a bouncing ball as it hits the ground and not a collision detection capability. The collision skeleton is exactly that, the shape of your avatar as it appears to the sim. The viewer does not have a physics engine that is used in its runtime operation at all. The render metadata views that you see, whether that be the "physics view" and the "collision mesh" view, are emulated. Occasionally this goes wrong and you get slightly odd behaviour. Where we do use physics is in mesh upload. The Mesh upload function has a physics tab and a mesh asset in SL has 3 possible representations of the physics shape. The most basic is the "base hull" this is the "plastic wrap" physics shape that you get when an object has "convex hull" selected as its shape. Next up we have what is probably the most common, the mesh physics, this is a physics shape defined by the triangles of a user-provided mesh model. However, that mesh-based physics is still only processed on the server side for collisions. Finally, we have the hull-based physics which it accessed through the optional "analyze" and "simplify" functions on the upload tab. These functions take the same user-provided mesh model and try to decompose it into a series of simple objects known as hulls which the physics engine on the server side knows how to optimise. To do this analysis, the viewer uses a small stub library provided by Linden Lab, which has a very specific limited set of functions to perform the hull conversion. Just a note on mesh upload and Havok, mesh upload is perfectly viable without Havok support, contrary to much urban myth. If your viewer of choice does not have Havok support (for example the current release of Firestorm 64 bit) then you will find that the analyze function is limited to the "default" method and that simplify is greyed out.This does not stop mesh being uploaded with the triangle physics, or even the default analyzed physics, it just means you have reduced options. The only other area of the viewer that "needs" physics knowledge explicitly, is some of the pathfinding Bullet is an open source physics engine that is widely used in the CG industry and is used in some Open Sim grids, again, it works on the server side and does not require client-side support. There is not a lot of current documentation and Linden Lab are a little tight-lipped about the specifics of physics on the server-side, where things like the algorithm for the physics cost element of the Object LI is incomplete in the wiki pages. A number of builders have discussions on physics creation but few cover the mechanics. As I have a foot in both the viewer dev and builder camps I have blogged a little more on the mechanics and the tools but even this is mostly implied knowledge and I would not claim to have everything right or complete. The best way to get answers is to ask in places like this, or inworld builder groups such as Mesh Dev and Builders' Brewery but as with all things, be aware that misinformation lives on forever and there is a lot of bad information that get repeated so often that it becomes assumed to be true. Hope this helps.

yeah that was an example of a bad physics design, I hate furniture I can walk through, it makes no sense, hence the table example in the my text, I *want* to be able to sit/stand/put plants, cups etc on my table and as you rightly say it is very very unusual for a moderately complex mesh of a moderate scale to have a download cost so low that a properly thought out simple physics will still remain lower. Frankly, it is either laziness or lack of knowledge in most cases, my hope is to make the latter harder to claim so that lazy designers are compelled to do the right thing or be shown for their laziness.

I'm not sure, but I'll try, the thought I had was to look at how the Havok libs encode a cube and replicate that. It may get shot down in which case the decision is made for us. I'm just finishing a couple of other tools for meshers at the moment.

Yep yep, totally agree, if you can be completely certain of the usage, (anyone trying to rez a coffee cup on a plant leaf is prolly not worth thinking about). My point on cost was more that the small difference will never be noticed by a user, it's only for us self-confessed "mesh nerds". In fact,a physics cost that small will always be overshadowed because even at 0.360 even the default server cost will rule the day when it comes to evaluating LI! Question, if/when I add "box physics" to the uploader, would it be preferable to add a Havok primitive or a Mesh one? Thoughts appreciated.

The simple answer is yes. It works. The more complete answer is "please don't". As with LOD models, it is preferable for the overall experience to have a physics shape that roughly (and it can be very roughly) matches the shape and volume of your item. The problem with a single plane physics shape is that it does not provide a good physics analogue of the item. Now there are many cases where you may not want physics at all, but please think very carefully for the following reason. In almost all case a box that conforms to the overall volume of the item is no more expensive (it will undoubtedly be less than the streaming cost) and is very simple to have just laying around on your hard drive. Have you ever tried to rez an item on the coffee table in your living room only to be told that you cannot? In some cases, with no copy items, you will find that not only did it fail to rez, but it also vanished from your inventory. Why is this? Simple, inadequate physics. When you drag an item from your inventory and drop it inworld the viewer takes over. First, it has to work out where in 3d space you are trying to drop it, to do this it converts the 2D coordinates of your mouse on the screen into 3D coordinate by projecting a beam (known as ray casting). This means that it draws an imaginary line from your camera into the 3D scene that is drawn on your monitor. That beam hopefully collides with a target and identifies which object has been "hit". In my example let's say the "hit" was on an object called "coffee table". It then works out approximately where on the object it hit and uses that same imaginary line to intersect with the bounding box (an imaginary box surrounding your object). This vector and the point at which it intersects the bounding box are then sent to the server and this is where the physics becomes important. The server has the physics shape of the object, more importantly, it has no idea whatsoever what the "visible" shape is, it can only "see" the physics shape. Its job is to decide where on the target object the item is to be rezzed. The server, therefore, takes the vector and follows the line through the object and the first point that the vector collides with the physics surface is the point at which the item will appear. If however, it does not collide at all, (because you missed the edge of the table or more commonly because the creator of your beloved table chose to skimp on the physics shape) what can it do? The viewer has said "the user wants to rez this mug of tea, on this table", the server says "but there is no table there" and thus it just throws a hissy fit and gives up. You get the sulky "you can't rez there" message and if you are lucky the item returns to your inventory. TLDR; The moral of the story is "be very careful about what you consider as not needing physics, especially if you are going to sell it to other users". There is a detailed Jira that we produced a while back that illustrates this. Footnote: I am actively extending the build tools in Firestorm at present and one of the items on my (longish) list is to provide a cube physics default. In theory, it is simple, in practice making sure I cover all the bizarre meshes you lot might want to throw at it, means it is not quite so obvious. Keep an eye on my blog, or these forums for updates.

Actually (as the aforementioned dev) reading your thread above it may well be that you are already using an alternative to OAuth. There is some information in https://auth0.com/blog/google-blocks-oauth-requests-from-embedded-browsers/ regarding alternatives. Are you getting an error code at all? I suggested whirly test another site that used google federated authentication and as per her note that worked which seems to suggest that (whether OAuth or not) this issue is likely to be implementation specific. I am not a web developer so I cannot give much guidance but if you are able to confirm that you are using one of the supported methods and give a little more details we can use that to guide further investigation.

Quick update teaser.... Today I was able to test the new 64 bit Havok capability in FS. I will stress that this is not yet publicly available but is likely to be part of the next release. This means that the 64 bit Firestorm will have full Havok support once again, just like its 32 bit version. The implication is that the little Magenta boxes will no longer appear and will instead be replaced by "pretty" physics shapes. I am demonstrating here using a new feature that I have added to Firestorm that allows you to see the physics shapes in edit mode as well as the old render metadata route. We are going to do the same test as above. Render a cube, adjust the hollow to demonstrate how the physics moves to mesh above 20% hollow and then flip to convex hull. In the previous animation, this resulted in a magenta box. In the Havok enabled version we see a blue box appear. I have to set the box partly transparent because the convex hull is slightly smaller than the containing object and is "hiding" inside.

Step by step: Enable physics view in render metadata Rez a prim change the prim physics to convex hull set the hollowness to >20% Why these steps? Prims are "speshal" a default prim is represented in physics by a very low cost physics primitive and you will notice that unlike meshes when it is painted blue it has no edges. This shows that we are using the optimised Havok box shape. If we leave the physics as Prim and change the hollowness to >20% you will notice that it suddenly gets dressed in triangles. This is a triangle mesh physics being applied to the more complex shape in an attempt to better reflect the actual visible shape. If we then try to turn that into a convex hull, the viewer cries foul, it needs the havok libraries, throws a little hissy fit and draws a pretty pink box instead.

OK, deep breath....you asked about the boxes, which is a completely diffferent thing to the tonal shading that Whirly mentioned. However there are a couple of things to note here with regard those, so I will first clarify that. Counter intuitively the physics coloration is not based on the physics cost but on the overall object cost. It has been this way since the original code was written. I am tempted to make it selectable in a future firestorm. The colours themselves are then defined relative to a viewer Setting (ObjectCostHighThreshold) and a linear interpolation is used to graduate the shades from "ObjectCostLowColor" through "Object CostMidColor" to "ObjectCostHighColor" based on a normalised cost. This is illustrated in the following graph which shows the default colours and threshold. I messed the labels up but effectively the X axis is the normalised cost and the y axis is the object cost. The plot is the equation shown (the normalised cost against object cost). The shading approximates the spectrum of colours you would see in the phsyics view. But what about those magenta wireframe boxes? Any wireframe cube is indicative of an error or limitation while rendering the physics shape in the viewer. If you are using the 32bit Firestorm or Linden Lab viewers you will not see these very often, typically they will flicker into view very briefly during loading because the asset is still downloading and be gone before you have time to realise. On the 64 bit firestorm, you see these a lot more frequently. to explain why I need to take a step back... Physics view is artificial.. my recent blog post about the "thin wall issue" illustrates one situation where the viewers get it wrong. The real physics is always calculated and enforced on the server however in order to draw the physics shape view on your screen, the viewer has code that "reproduces" the physics shapes. For some scenarios it is easy, a mesh with a non-analysed mesh physics shape is literally just another mesh that is sent to the viewer as part of the asset data. However, when it comes to convex hulls, the viewer does not know how to render them on its own. It uses a helper library that is licensed by Linden Lab from the makers of the physics system Havok. Until very recently the lab did not provide a 64-bit Havok build and as such there is no current 64 bit TPV that is able to decode things like convex hulls. Thus, there are a number of scenarios when the viewer cannot show a physics shape because the necessary library to provide the data is not there. Note though that this ONLY applies to the physics view, it has no impact at all on the physics collision shapes because these are handled on the server. In fact the boxes, which are 50% of the bounding box of the object (fwiw) come in a range of colours, the reasons for the colours vary slightly depending on whether it is user mesh, with analysed or non-analysed physics, whether it is in convex hull display mode or prim physics mode etc. Here is a non-definitive list. Orange (255,255,0) - viewer cannot decompose analyzed hull physics (Havok is not installed) or the user mesh physics has not downloaded yet (similar to cyan) Magenta (255,0,255) - this is a standard prim in convex hull mode or its a mesh with no physics shape (only the default base hull) and we don't have Havok. Cyan (0,255,255) - the physics data has not yet been retrieved from the CDN I am writing a definitive guide which will appear on my blog but I am going to wait until we have a Havok enabled 64-bit Firestorm in release as that will make most of these boxes vanish. regards Beq x

As Whirly notes, based on the screen shots the Aditi build will be charged only for the root mesh physics, as the root cannot be None. While on Agni you get charged for both parts. Also, while it ultimately makes no difference to the result if physics is enabled for all parts, the switching of the root prim to be the deck on Agni, while it was the steps on Aditi would give you different results if you had both sets set to None (Agni would carry the Deck Physics cost while Aditi would carry the steps physics cost). Regards Beq

@arton Rotaru Havok being the issue only applies if the physics is analysed. If you upload the triangle mesh physics shape then that will not be the case. That said we are expecting to have the full Havok decomposition restored to the 64 bit FS in the next release....watch this space. @Chic Aeon I'd love to work with you on resolving or at least understanding this if we can't resolve it. If it is an issue in the viewer then I can hopefully fix it, if it is a workflow thing then we can work that out.

Hi @Chic Aeon There's a whole bunch of little details in this thread that are worth explaining.... TLDR; version FS 5.0.1 has broken crappy physics. FS 5.0.7 FTW Havok support is important in very rare cases (analysed mesh only) a bunch of other stuff. Verbose version..... This is (probably) expected behaviour but it's impossible to tell for sure without seeing the meshes and the settings. The analyse function, tries to create a nice physics collision shape and will do it's best to match the shape of the mesh in the minimum number of "hulls". Typically, there are a range of settings available (which you can see in the lab viewer), but in the 64 bit viewer, and in the OS viewer regardless of 32/64 bit, the libraries used to perform the analysis are not present. As a result, only the most basic analyse function is provided and the results are pretty limited in anything but straight forward cases. In you case it may well just throw a hissy fit and fill in gaps. This is quite possibly a part of your problem. When we released Firestorm 5.0.1 (the bento release) just before Xmas, a "minor" bug slipped in from a Linden Lab code change that was merged into the final build. The bug completely messed up the normal way that bounding boxes and thus physics shapes were positioned. It was rapidly backed out by the Lab in one of their frequent updates, however, because we only release Firestorm periodically, mesh physics upload, particularly multi-part mesh, was problematic and the advice we gave was to use the Lab Viewer for uploads until the fix was available. The good news is that version 5.0.7 DOES fix the issue and uploading Mesh with Firestorm is once again back to normal. The root of this problem almost certainly lies in a combination of analysis and OS/non-havok versions of the viewer. I'll explain why mesh physics is "different" in a bit. Analysed Physics is, in theory, more reliable and "better" for SecondLife, though in practice that is questionable. So what does analyse do and why? Second Life uses a physics engine called "Havok" to do all of its physics calculations. The Havok engine uses special physics shapes, called "hulls" to optimise the calculation of collisions. The cheapest is the sphere (because collisions can be reduced to "is anything within 'radius' metres from my object centre"), Sphere and cylinders equally have a highly optimised physics collision test. The analyse function is used to convert a triangle based mesh into a set of "hulls", making a robust and efficient physics collision shape. Havok is a commercial engine, it is not available on OS and neither is it (currently) provided for 64-bit viewers. This is why the old viewer that @Aquila Kytori was using had that (misleading) popup. In practice, almost all Havok usage is server-side and hidden away but there are some functions that need viewer-side support. One such function is that physics analysis. In order to enable this, the Lab kindly makes a library available under a special sub-license but because they do not have a 64-bit viewer release they do not provide the Havok library. This is about to change because the lab is on the cusp of launching the 64-bit Alex Ivy viewer. We will then be able to provide a 64-bit Firestorm with FULL Havok support. Without the Havok support, Firestorm performs a "poor persons" analyse which is really not very good and a problem that was further exacerbated I suspect by using the bugged 5.0.1 release. So what is the difference between non-analysed mesh and analysed mesh? In non-analysed mesh, the physics engine has to use the triangle in the physics model to perform collision detection. Big triangles are nice and friendly and relatively low cost. long thin triangles are however a nightmare as the physics engine has to work really hard to work out whether things are intersecting. It is this reason, more than any other single reason, that explains why you should make you physics shape as simple as possible. It also explains one of the least well-understood issues with non-analysed mesh. The reason it gets more expensive as you scale it down. Smaller triangles, require far more accurate checks and thus cost more. As you shrink an object with non-analysed physics it's cost progressively grows. until it goes crazy high.....An example taken from my blog is this 9000LI tortured torus. One of the primary advantages on analysed physics is that it is constant no matter what the scale (sadly in most cases it is "constantly" higher than a sensibly built triangle mesh). @Aquila Kytori gives an excellent example of how a mesh physics can be made, very efficiently. It has one slight drawback which you may never notice in practice, which is that as a single planar physics surface the collision detection can sometimes "miss" allowing for things to pass through the wall. (it's not normally a real issue) There is one other mistake that people make, and I have seen it so many times that it features in a blog post about physics issues. It happens when people make a mesh wall, with a cutout window or door, and don't analyse it. If the wall is less that 0.5m thick then a "safety feature" of second life kicks in and forces the physics shape to behave as if it were a solid hull. The reason for this is simple and explained above if the LI were to continue to grow unchecked as the object got smaller then it would go asymptotic as its scale approached zero, the legendary infinite LI prim :-) So in summary Listen to Aquila, she talks sense But, sometimes analyse IS the right choice, but not that often. Ditch Firestorm 5.0.1 ASAP it is broken and buggy and we have given you a nice new shiny one. :-) Look out for Havok enabled 64 bit firestorm in the future and it will give you many more analysis options for those times when you really need it. And finally.... I am working on another blog post all about physics in the very near future. I hope this epic first ever post in the forums is vaguely useful, in answering a bunch of the unknowns. Love Beq x