Jump to content

Beq Janus

  • Content Count

  • Joined

  • Last visited

Community Reputation

377 Excellent


About Beq Janus

  • Rank
    Advanced Member

Recent Profile Visitors

365 profile views
  1. Beq Janus

    Prim to Dae

    I am really enjoying using Blender 2.8. From a UI and interaction perspective the biggest change for those of us who've been at it for years is the switch to left mouse select. I actually turned that off on 2.79 about 12 months ago because it just makes shifting between programs less traumatic (and using a tablet easier), so my muscle memory has been retrained now so that hurdle has been crossed. There are some other organisational changes as well, the biggest one for me is the addons no longer appearing on the left in the tool box but on tabs on the right, but once you get your head around that it is fine. I'm teaching myself sculpting at the moment and I can say that 2.8 is way better performing than 2.79. It's still very much beta though with a few werid things happening but the new collections seem a much neater way to organise things than the old layers too. It is occasional;ly frustrating, I struggled for ages to find where auto smoothing had moved to for example.
  2. Beq Janus

    Mesh Upload

    Overall land impact is defined by the larger of the three components download/streaming, physics and server. At upload server will ALWAYS be 0.5* the number of links in the linkset/group, the download cost is defined by a published algorithm and will match that shown in the uploader. I have a blog post from many years back that dissects the streaming cost, it is not for the faint hearted though, this is not in an attempt to make anyone feel stupid but an attempt to explain a specific algorithm that is used within second life, and to go some way to explaining why it was defined in those terms. http://beqsother.blogspot.com/2016/07/the-truth-about-mesh-streaming.html this discussion gets more technical again as it spills over into https://beqsother.blogspot.com/2016/07/blender-mesh-data-deep-dive.htm As that blog illustrates the download cost is indirectly related to the number of triangles. but will vary depending on how well the compression software is able to squeeze the mesh data. So.... putting download cost to one side that leaves us with physics. The physics cost shown in the uploader has always (until the newest firestorm) shown the convex hull cost of the mesh. But there are a few subtleties that need to be teased out here. The convex hull physics shape is mandatory. it must be present for the mesh asset to be uploadable. It is created by the viewer on your behalf and uses the available LOD models to do this. A convex hull is single surface that wraps your object, I tend to liken it to what we brits call "Cling Film". Much like the wrap above it follows the outline of the object bridging any concave areas. An extreme example would be a mixing bowl with wrap stretched over it, the top would be flat. For the convex hull in Second Life the viewer has to be able to produce this shape using no more than 256 vertices. If it cannot manage this then you will get one of those magical MAV_BLOCKING_MISSING errors that we all love. The missing block being the mandatory physics data. We can also provide a user-defined physics shape, and this can be presented in one of two forms, a low poly mesh, or a set of up to 256 convex hulls. Both start from a user model. If you select a user mesh shape, by specifying one of the LOD models or uploading your own custom mesh, then by default the Mesh physics is computed. Mesh Physics cost is defined by an algorithm that is not published so we cannot reverse engineer the results (not without a lot of work at least), however, it is based on the number and the area of the triangles that comprise the specified model. In general, the smaller the area the larger the cost with long thin triangles being more heavily penalised than small equilaterals. The cost of the physics being inversely related to the area of the triangles is what leads to the extreme physics issues (and the "thin wall" cap) associated with small mesh items. These are discussed in https://beqsother.blogspot.com/2016/07/when-is-door-not-door-and-other-things.html. The final side-effect of using a mesh model for physics is the "degenerate triangle". Another one of our lovely MAV errors, degenerate triangles are triangles that are so thin that the uploader simply rejected them and refuses to accept the model for upload until you fix them. then new Firestorm uploader highlights these better than previous viewers but in most cases when you see this error it should set an alarm bell in your head telling you that your physics mesh is too complex and it is time to rethink. To avoid the scalability concerns and remove the degenerate triangle problem you can use the Analyse Mesh function. The analyse function takes the user mesh model specified for physics and tries one of a number of selectable algorithms to decompose the shape into a series of convex hulls. As before the maximum number of vertices in a hull is 256 and the maximum number of hulls (per mesh item in the link set) is also 256. The charge for an analysed physics shape is derived from the number of hulls and (I think) the number of vertices of those hulls. This can lead it a very expensive physics shape, but the resultant shape has a fixed cost no matter what scale and does not get affected by the "thin wall" limit thus making it ideal for build components that may be resized. analysing an arbitrary shape and working out how best to present that in physics is a complex task and your results will be far better if you leave big heavy hints for the code, one common way of doing this is to represent a physics mesh as a series of discrete cubes with a small gap around them. The hull analysis is then able to wrap each of those in a nice convex hull and give a stable, predictable shape. The real issue with physics costs has always been that it is largely guesswork. You don't know for sure (unless you've got enough experience to think it out for yourself) what the cost of setting physics to prim will be when you get the item in world. The new Firestorm mesh uploader (coming to the SL viewer real soon) provides you with information that you were never given before. In a new panel on the upload screen it will show you the cost of the convex hull alongside the cost of either the mesh or the analysed physics. The following very contrived example shows a fox sculpt that is about 7000 triangles (I'm just learning to sculpt don't shoot me for my artistic skills) it is large scale (6m high and 5m long) Fullscreen version: https://i.gyazo.com/ef67b31b06f132b0e4148a3b31835caa.mp4 I go with the defaults and see a convex hull cost of 7.2 LI I use the generated LOW LOD for the physics without analysing and the cost is 45.7 LI based on the 436 triangles that comprise that LOD at that scale) Note that if I were to change the scale to be smaller (which is likely once in world - nobody wants a 6m fox) the physics cost would escalate. I use the analyse function with high-quality setting selected to give a better match to the shape. This gives us 73 hulls at a cost of 43.2 LI We finally select a user-defined mesh. At just 48 triangles, this gives a physics cost of 5.2, and note also that the convex (base) hull has reduced to 3.1 because it is being calculated from the user-defined mesh model now. Finally, we analyse this and get 7 hulls at a cost of 2.4 LI It is worth noting too that the algorithms that perform the decomposition appear to have an element of randomisation to them. As a result, you can get small differences in costs each time you repeat the process. As this code is unavailable to us outside the lab, there is not much more to be said on that. It may be that the randomisation is not in the decomposition but in the fact we are using the GLOD generated LOD models which are known to use a random seed and thus give varying results. I hope that this helps explain things somewhat. The high-level concept is simple enough to understand but it is not a simple process to understand if you are focussing on the details. There are many nuances and various "tricks" that people try, but this summary I think has covered most aspects. Beq
  3. Beq Janus

    Prim to Dae

    Coming to this rather late in the day. as @anna2358 stated this is a licensing issue. I would like to correct a misunderstanding here though " I need to downgrade FS because I usually install full versions". The OpenSim edition is the downgraded version in technical terms and it frustrates me that many people use that version even if they never use OpenSim. You should use the dedicated SL version unless you have a good reason not to, the only good reason is that you are using OpenSim. The OpenSim version cannot use the Havok license and thus is less functionally complete. It is harder and harder to keep OpenSim and SecondLife together with the lab actively creating new projects such as Animesh, BOM and EEP that are not available on OpenSim (though I have heard a rumour that Animesh is coming to OpenSim). In the case of Linux, it is more nuanced, as even on an SL specific version there is no Linux version of Havok available to us, this may change if we can get enough contributed effort for the Lab to reincarnate their Linux viewer. Linux is sadly hanging on the thread of support at the moment, Vivox dropped voice support for Linux a few years ago and luckily most of the updates since have remained API compatible but should there be a significant change in the future Linux will lose native voice (wine to run SLVoice,exe is probably the workaround but cross that bridge when we come to it) As for exporting of prims to mesh, the UVs should be fine but it will depend on the operations that you perform and (as noted elsewhere) ensuring that the linksets are constructed to keep within the limits (8 textures etc) in such a way as to allow them to be imported without the uploader taking it's rather brutish actions. When exporting, it is important to make sure that you tick the box marked "consolidate texures", this will ensure that the same material used in different prims will be tagged with the same material ID in the exported DAE. You can test this easily. create two cubes set the top face of each to RED set the front face to BLUE on one and Green on the other. "save as collada" leave "consolidate textures" unchecked. Load in Blender (file->import collada) and click on the objects, (they are separate objects initially) You will find that the first has Material-0 Material-1 Material-2 and the second has Material-3 Material-4 Material-5. Ctrl-J to join them and you resulting object has 6 materials. Repeat step 4 but this time tick the "consolidate textures" box. Load into Blender again and you will note that the individual prims not share Materials and when you join (Ctrl-J) the resultant Mesh has just 3 materials. If you work a lot with Prims (I use them frequently for prototyping and establishing scale or for matching a new build to something inworld, then one of the inworld prim2 mesh tools (Mesh Studio and MeshGenerator are the best known there are others as well) can be a worthwhile investment. These tools use an external server (and as such are dependent on 3rd party services which may one day vanish) and produce a far cleaner mesh than a simple "save as" does. for example in MeshStudio you can set the resolution to 2 for straight edges which removes all the unnecessary vertices that you get with a normal prim , it also allows you to set the "resolution" of curved edges, which is useful for making a nice LOD or physics model. By default a curve replicates the SL standard of 24 sides to a circle. if you make this 8 then it will generate octagons. As stated, these tools are dependent upon an externally provided service, both of them have been very stable lately (though we did just have an outage on MeshStudio but it was the first for over a year as far as I know and it is back now). A couple of years ago, an earlier version of MeshStudio was giving more frequent problems and I wrote a short tutorial for people who felt paralysed at not having the tool they use available and lived in fear of Blender. It explains how to clean up a simple prim export without destroying the UVs, while also explaining why the tools still have value. The blog is here http://beqsother.blogspot.com/2016/07/what-did-mesh-studio-ever-do-for-me.html The "Save as" cleanup in Blender is mostly covered in the embedded video
  4. Beq Janus

    [Article] How To Make Low Poly Look Good

    Great article. I love the low poly look that is part of many current indie games. One great example is Equilinox, an evolution-based game from a dev known as ThinMatrix who makes some excellent video blogs on his development process as well as a lot of technical blogs on writing a game engine.
  5. Beq Janus

    Micro-gaps between mesh components

    As noted above the height issue is the first thing to check. In these types of problems, my first advice is always to rez the items at sea level and check again. Rounding errors do occur and can affect all rotation and positional operations. Build platforms, despite their popularity, are in general, not the best idea we ever had as users 🙂 As @Orwarnoted scale affects these too. It all comes down to playing nice, When the viewer draws an edge on the screen it is a series of pixels in an approximation of a line, the length and angle of the line determine where the steps in the line occur and have lines of different lengths is asking for trouble. Similarly, within a mesh asset, all coordinates are stored as 16bit signed integer values (your mesh is effectively snapped to a grid of 65536 (64K) points when you upload it. If one part of your build was 64m high then the resolution of the points within it are quantised to just under 1mm (or to be exact to 1/1024th of a metre), while the 6m high piece next to it has 10 times that "internal" resolution. There are rounding and scaling operations taking place at all levels of a 3d scene, being aware of some of this can help you design your products to work with the renderer more smoothly. Another common source of these is related and comes from bad topology, in particular from unconnected vertices. This gyazo shows an example I helped fix a few weeks back. In many cases such as the one below, the user is not intending to butt things up together and simply needs to change the construction (this build was prim2mesh it actually had more verts than I've shown but none of them were aligned/merged), when you do need to then carefully thinking about the design will save you a lot of pain.
  6. Beq Janus

    Has there been any update on project ARCTan?

    Speaking of which....hover height bug should be fixed now https://status.secondlifegrid.net/incidents/95ylzcn80mp1
  7. Beq Janus

    Has there been any update on project ARCTan?

    In the content creator meeting on Thursday Vir said Arctan is still on the list, but nobody is active on it (prolly cos Graham is focussed on EEP) BOM is not abandoned at all, the reason Anchor is working on the hover height bug is because it was cauised by bake server changes for BOM. Anchor has now fixed that bug and you should see it rolling out in the coming weeks.
  8. Beq Janus

    Can't See Animesh

    I agree with Fiona, in technical terms the implementation of Animesh is not significantly different to rigged mesh, there is nothing special that needs to be done beyond running the correct viewer. You mentioned bugsplat, which is a preview, and it is possible that that viewer has not had the Animesh branch merged in, as Fiona noted, if the viewer shows version 6 or above then you should be fine. I would note that there is a lot of junk content on the marketplace that is labelled as Animesh and is not in any way whatsoever related to Animesh, just a typical scam by unscrupulous merchants. There is, however, an increasing amount of legitimate content and I would encourage you to get the sample content that Fiona linked. The "Animesh teddy" in that set can be worn, in which case it will hang limply in your hand, swinging gently, or rezzed on the ground, in which case it will wander using pathfinding.
  9. Beq Janus

    Frame rate

    .When testing these things it is important to ensure all things remain as equal as possible. The latest Firestorm is a preview, this has a couple of implications that stem from the fact that you have both the release (5.1.7) and the preview (6.0.1) 1) If you are using the same cache location then the cache that you use will be cleared each time you swap back and forth between the release and the preview, this will cause you to be slower until the cache is regenerated. 2) If the two versions have a different cache then make sure that you have whitelisted the preview cache location and any other files with your AV software, this stops it continually hammering your cache folder to scan files while they are being stored for cache. As other's have noted, double check all your settings, and the performance depends on what it is you are looking at of course, so to do a reliable test find a stable place (this is harder than it sounds) and make sure that you have the same windows open/closed in the viewer (inventory/chat etc all have an impact on fps), make sure that your outfit is identical, including HUDs.For comparing pre-animesh viewer and animesh viewers make sure that there is no animesh in the scene so that both viewers are doing an equivalent job. Test with both viewers, one after the other, giving each time to re-cache and stabilise if necessary. With all the above confirmed the same, I'd be interested in the results. I cannot promise to help resolve it but your experience is contrary to what (in general) I expect from the v6 release compared to the v5, so my curiosity is aroused. Regards Beq .
  10. Beq Janus

    Alpha sorting different for Rigged Items

    The scaling would probably lead to rounding errors. The vertex ordering is key, this is something that the onion skin body and head makers have been exploiting for years. It's more a fluke than anything else really. Fluke may be a bit strong but relying on the ordering of vertices to make something render properly is a pretty fragile foundation you can see a point in the future where it all goes horribly pear-shaped.
  11. Beq Janus

    Why does (some) mesh do this?

    No argument here, but that is a creation problem, until people stop making clothes that vanish at medium LOD it remains an issue. As for spreading LOD swaps, the way that the viewer works it really doesn't make an awful lot of difference you'd be hard pushed to discern the benefit of that distinctly from the rendering cost reduction associated with a lower LOD. staggering the LOD swapping from a visual perspective "should" look better, insofar as items should swap when the onscreen resolution is low enough that the two models render very similarly, but as you know this relies on the efforts of the creator as well as getting the swapping algorithm right. My preference is actually to LOD swap based on screen space resolution, if you are rendering a high poly mesh into 5x5 pixels on screen then clearly the LOD swapping is not happening properly and in an ideal world the viewer ought to be able to work at least some of that out.
  12. Beq Janus

    Do you rely on bump maps in your meshes?

    Do you have the latest Substance? The new export viewport function is perfect for SL and if I understand it correctly gives you all the baked in goodness in a single diffuse texture. Use with care, of course, baked in lighting can be the death of an effect if used too much but if you stick with largely ambient lighting and comparatively bland reflection maps you ought to get a decent effect that non-ALM users will appreciate and which you normal maps will enhance. https://gyazo.com/ef3bed2a2a410ee688807fc99c67ed87
  13. Beq Janus

    Blender 2.8 anyone?

    hah! that would explain it. It was covered over by the windows task bar. Thank you that makes a lot more sense now.
  14. Beq Janus

    Why does (some) mesh do this?

    Worn rigged mesh uses the same LOD algorithm as any other object in Second Life. The only difference between worn rigged mesh and non rigged mesh is that the attachment uses the size of the entire avatar as its Bounding Box size to calculate swapping the LODs. So even some tiny jewelry will have the effective BB size of the avatar. This can be quite handy when you, for example, create some full body armor out of several small pieces. You don't have to worry about inconsitent LOD swapps because of the different sizes of the meshes. A couple of notes on this (Arton's post is the succinct version, this is a more detailed version). As Arton notes, rigged mesh LOD behaviours according to the same algorithm but it is affected by a couple of other things 1) the bounding box of the avatar 2) a bug that makes the effect of the bounding box even larger. The algorithm/equation uses the radius of the bounding box to determine the size of the mesh and thus (in theory) how large it is in the context of your displayed scene. A big building is visible from half-way across the region but your earring is not. For rigged mesh (and notably only rigged mesh not unrigged worn mesh) the radius used is (supposedly) the avatar bounding box. This has good and bad effects, on one hand it means that all your attachments LOD decay at the same rate (as Arton points out this stops things like your panties vanishing before your dress) but on the other hand it means that all your attachments LOD decay at the same rate 🙂 (so your pinky ring is displayed in all its overly detailed high poly glory for exactly as long as your body is despite them being vastly different sizes. But it is worse than that, I reported a bug a while back whereby the radius used for the avatar is not the radius at all but the diameter meaning that the LOD decay rate is half what it ought to be (or in other words, that pinky ring lags you out for twice as long as it ought to). See https://jira.secondlife.com/browse/BUG-40665 for more info For #2, there is a further issue. because the bounding box of the mesh can be artificially extended by the way that some creators organise their meshes. This is detailed in this Jira https://jira.secondlife.com/browse/BUG-214736 I should also note that the Animesh viewer release has changes that dynamically recalculate the bounding box. This can affect your rigged mesh LOD behaviour but because of the preceding points it is unlikely to do so for the majority of cases.
  15. Beq Janus

    Why does (some) mesh do this?

    Not understanding smoothing in the external app is one cause but a lot/some of the time it is because they erroneously use the "generate normals" option in the uploader which is guaranteed to mess up your nice smooth shading. Often people do this because it has a small impact on the LI (because the resultant mesh compressed a little more when zipped). I've even seen people recommend it as a default step! I've not considered the render speed aspect before, I'm not convinced it makes much if any difference, but not having looked at it I won't rush to any conclusion.