Beq Janus

March 24, 2018

8 minutes ago, arabellajones said:

If I can't trust the numbers for the LOD distance that I get, how can I judge whether the detail of the lower LOD models is too low?

That's part of what I do. I am told that the Low-Lowest switching distance on the rigged mesh I made is 107.1m (I love the excessive precision...) which means it subtends about 3 milliradians. Figuring what that is in screen pixels depends on the physical screen and the actual angle of view (a lot of people confuse zoom and dollying, and right from the start camera distance changes have been wrongly called zooming in the documentation). I've never found any plausible numbers for the default angle, but, from the Mini-map in Firestorm, and the view indicator shown, it's not far from 2 radians. With my screen, and erring on the side of detail, I decided 3 milliradians was 6 screen pixels.

Yeah, excessive precision. The difference between 6 screen pixels and and 5, at that distance, is about 18m

Anyway, when I dug through the JIRA I found a bug report suggesting that some Linden had used the wrong calculation, and doubled the switching distances for rigged mesh. And I read the conclusion as that nothing had been done to fix it.

But if that is the way it works, where is it documented? Where's the link from the LOD explanations to that particular JIRA entry?

I can see the point of all rigged mesh on an avatar using the avatar bounding box as the base for the LOD switching, but when you dig into it, it's the radius of the bounding box. OK, but then what about people who want to do the giant robot thing? Use the largest bounding box of the set. It still makes sense, but it's all rather pointless if you don't bother to tell people.

Apart from the giant robots, just using the avatar height would work pretty well., but how quickly can you get that number?

If you are using my tools in Firestorm you can trust the numbers under the following conditions.

1) You are examining either a single mesh or are looking explicitly at a link in the linkset using "edit linked".
2) You are comparing to a typical setup. The table allows for LL default for on mid through high-ultra settings i.e. 1.125, likewise, the same settings range for the "FS default" 2.0. The final column is your personal setting.

The number shown is the value that the viewer pipeline calculates as part of the LOD calculation process, thus it is the value used to do the actual LOD switch. There may well be some use cases that I missed but for the common options that number is right. The value for rigged mesh is very wrong, and yes, nothing is likely to be done about that directly because to do so would cause outrage due to all the mesh bodies that suddenly looked like garbage.

If you have a particular problem with the precision, raise me a jira on the firestorm bug system (jira.phoenixviewer.com) and I'll consider it when I get back to coding after Fantasy Faire.

The commentary around the number of triangles in LOD models is not (or should not) be about how low they are, to some extent, it is the opposite. You approach is at the scientific end of the spectrum, far removed from what most people are doing, the focus for good content is to get the balance of detail right. The problems being discussed in these threads tend to be around the production of items (typically non-rigged) that under all normal user settings would fail to display nicely in a perfectly reasonable scene because the creator has minimised the lower LOD models and expects the user to compensate by cranking up the LOD multiplier. However, while it is bad practice in non-rigged mesh, it is very common practice in rigged mesh because there is almost no chance of it LOD decaying at anything approaching the visible thresholds, as you noted for your 100+ metre visible item and frankly in that regard it is "excusable" because there is a good counter-argument that if a LOD is never going to be shown by the system then wasting a few megabytes of data to send (and manage) the LOD models is utterly pointless. Of course, we then have the fact that some people make items extremely complex in the High LOD "just in case" someone spends time to zoom in close and photograph their shoes.

The current LI equation "charges" you for every triangle you use, with a higher cost per tri in the lower LOD models, this leads to the situation where a creator can offset their overly complex high LOD model by excessively minimising the lower LOD models. What is needed is a balance, a well constructed high LOD model that uses the tools we have such as materials, to efficiently boost the details, and a good set of lower LOD models that work well for the expected use case and have a appropriate volume/profile/silhouette as it slips into the distance.

As you say, the guidance is poor and mixed, there is little to no consistency around best practice because of a number of legacy conditions that affect the content we have. As the lab continue their experiments to redefine how our stuff gets costed, we should all continue to lobby for quality official guidance.

March 24, 2018

Physics upload is nothing to do with the server, the mesh decomposition happens in the viewer, so unless you changed the viewer you are using the upload would not be affected.

The server is responsible for implementing the physics once it is rezzed of course, but if there was a glitch on the region you were using or something else was awry then those meshes should be fine now, perhaps try another region?

I just tested a shop shell and it worked fine. Both analysed and non-analysed are fine. I can't show you the images cos someone would yell at me!

Happy to take a look if you are still having issues, but I cannot reproduce it as described here now (on Agni).

March 16, 2018

21 hours ago, OptimoMaximo said:

But i wonder: are we sure that the meter scale rigged attachment is the correct one for calculations, given that the real size of an avatar at its beginning is centimeters scale. So here i'm back to the scale factor. If the meter scale attachment snaps to rig and then the avatar scales up, the distances in the linkset scale up as well, giving you a 16 meters bounding box: what previously was 16 centimeters distance, scaled up by 100 gives you 16 meters. Because, as i was saying in my theory, the ITEM (transform node) scale isn't reduced to centimeters, the skin does it on the geometry (shape node), then the avatar goes to meter along with all the hierarchy's children, including the item transform, which size didn't actually change to centimeters. Hopefully i made my theory clear

8

I think I understood, and it would be a bug if true - and very worthy of a Jira - but I have a problem with the theory. Why do you state that the real scale of an SL avatar is cm? Unless I am missing something (which is entirely possible, I've poked @polysail as she is my skeleton and rigging guru and hopefully she will confirm); internally models (the skeleton included) are in normalised units (floating point 0.0-1.0 quantised into a 16bit integer - actually in this case -0.5:0.5 but you get my point). All unit based conversion happens prior to uploading and human scale units cease to exist thereafter. The models are then scaled based on either their object's input scale in world coordinate (metres) or for rigged mesh, the avatar shape's scale. So there is no input scale to be lost at this point. The same applies to any attachment.

When a weighted item is applied to the skeleton it is transformed to fit to the skeleton. This is not the same as scaling because each vertex has a different weight, moreover, the models were all converted to normalised object space coordinates (those pesky 16-bit integers) on upload.

In a link set. each object has its own object space, and its own bounding box, but the relative positions of objects to one another are maintained in world space, this is where I get a little more patchy as I don't have time to go check the code here, but given that with a script we can alter the relative positions of components of a link set it would appear to make sense that these are in world space, or at least in an independent space (hence the 64m linking range?). I think the point here is that rigged vertices are weighted and thus do not affect the BB very much, but object positions and unweighted/non-rigged objects do.

March 15, 2018

5 hours ago, ChinRey said:

I was afraid I exaggerated in my first post but this is actually far worse than I could possibly have imagined.

There's intentional and then there is intentional.

The maker of the top in my example wasn't aware of it at all, he just had a habit of uploading in small size and couldn't understand why people complimented him for the low ARC until I told him.

Other makers know that you can lower the nominal ARC of fitted mesh by reducing the upload size but they don't seem to understand that they are just exploiting a loophole - they genuinely think that reducing the ARC that way actually reduces the render load. Maybe they should have known better, maybe not. Everybody have to make up their own mind about that.

The fact that Maya defaults to a mm scale and thus maps everything smaller into the SL metre scale means that for many that reduction is just the default. Which in fact is worse, if the default "no action" behaviour is the bad behaviour then people have to try hard to be "good" citizens.

March 15, 2018

6 minutes ago, arton Rotaru said:

Sounds like a clever trick to prevent rigged mesh from switching LODs.

intentional or not, that is certainly the effect it has

March 14, 2018

So I believe I have got to the bottom of this.

It is not that something has changed "recently" as I had intimated, or rather it is, but it was not the viewer ... it was ME.

Remember the Jira I linked (https://jira.secondlife.com/browse/BUG-40665). It is correct 2x the BB radius appears to be consistent. However what was confusing me is that if you look at the photos in the Jira, each one shows my avatar as applying a Radius of 2.8(ish) m, my BB diameter.

When I was making the post earlier today my BB was a whopping 16m....Could it be the Bento had changed the bounding box size?

Well no actually, at least not directly.

Watch this.....(static photos follow which show this more clearly)

https://i.gyazo.com/153e2dedd5ec39322eaa202d4fe45267.mp4

we start with plain old headless Beq... who is modelling a rigged mesh dress the pulsing pink box is the bounding box. Which is not the same as the hitbox, or related to the scale of the avatar per se, but is instead the visual extents of the drawable objects that make up Beq as we know her. The BB is around 3m diameter

I add a rigged mesh bento head and ... BOOM... 16m BB

why is this? well, it is not the rigged mesh, it is not even the bento... it is the scale of the attached object overall as a link set.

There are a number of green boxes pushed many meters away from the head that force up the effective Bound Box size. The result is that in combination with the rigged mesh radius bug, and what I am now considering the avatar scale "bug" (though it is arguably a feature) we have an avatar that will NEVER LOD swap below medium and rarely LOD swap to medium.

The Jira that I created was an addendum to a Jira raised by @polysail on the reason that ARC is broken because the ARC is based on the actual size not the "LOD size". So here we have an extreme, I can wear a 150,000 triangle rigged mesh bento ring, and my bento head and that ring will be "costed" at 0.1m radius for ARC, and yet be fully "visible" across the entire region.

oops?

A new Jira will appear in the next few minutes.

EDIT: Jira for this - https://jira.secondlife.com/browse/BUG-214736

March 14, 2018

9 minutes ago, OptimoMaximo said:

I've just run some more testing. Render volume factor still down to 0.5. This time i set my rezzed rigged mesh bounding box to be double than the avatar's. what i'm getting is still that the rigged mesh switches to lowest LoD at approximately double the distance than the rezzed, avatar-double-BB sized item does.

I've run the example script found here http://wiki.secondlife.com/wiki/LlGetBoundingBox and doubled the size when the primitive parameters are applied. Perhaps the bounding box that LSL gets is the size of the hitbox (as it appears to me when running this script), while the viewer code takes the static mesh's BB instead? Which would explain why this difference in distance: an avatar in TPose has a quite larger Y axis size.

Trying to look at this now and I think it may have been made worse "recently". Before, I only looked back at the binRadius call and the fact that it is not divided through. If the input binRadius is also wrong then it would be worse still. You can see the actual scale in use using my Mesh Info tool. where that scale comes from is more involved, I've gone back two levels (shown above) and illustrated that it's broken but I've not gone back any further than that. That radius is "very wrong"

March 14, 2018

43 minutes ago, OptimoMaximo said:

It makes sense, using the avatar's bounding box is useful to have consistent switch and i understand the design. But why use a different calculation? it's like having the render volume factor doubled on avatars at all times. I will further test, setting the rezzed object's bounding box to double the avatar's BB.

2

As I say, that part is a bug, or at least nobody has explained to me anywhere why it was chosen not to halve the value. My belief is that it was probably a straightforward mistake.

The "radius" used in the LOD calculation is calculated in the following code

	if (mDrawable->isState(LLDrawable::RIGGED))		// If this is a rigged mesh
	{
		radius = avatar->getBinRadius();		// get  the radius (see comments in thread below)
	}
	else							// for non-rigged mesh
	{
		radius = getVolume() ? getVolume()->mLODScaleBias.scaledVec(getScale()).length() : getScale().length();
 								// Here we use a thing called the LOD Bias * the scale....(see below)
	}

For Rigged mesh we use "binRadius" which you'd think seems sensible...until you look at what binRadius does

Here is the function getBinRadius()

F32 LLViewerObject::getBinRadius()
{
        const LLVector4a* ext = mDrawable->getSpatialExtents();        [ Get a vector array of the extents of the bounding box (the coordinates of the corners) ]
        LLVector4a diff;                                                                                  
        diff.setSub(ext[1], ext[0]);                                   [ subtract the lower, back corner, from the upper right corner giving the diagonal length of the BB ]
        return diff.getLength3().getF32();                             [ Return that value....effectively the diameter, in spite of the name. ]
}

For non-rigged we use getScale() which also returns the size of the avatar hitbox (a diameter) BUT we use the scale bias. this is setup based on the object type (historical adjustment for certain prim shapes). It defaults to 0.5 (it can be slightly more but that's beyond the scope here)

	mLODScaleBias.setVec(0.5f, 0.5f, 0.5f);

So taking the scale (diameter) and multiplying it by the bias gives the radius.

My guess is the developer who wrote the rigged mesh saw "binRadius" and decided it was already a radius.

March 14, 2018

On 11/03/2018 at 9:13 PM, OptimoMaximo said:

So here is my theory about it:

Since the scaling operations aren't accounted, the bounding box size of the object is being wrongly calculated when skinning comes into play, basically moving the geometry to fit on the basic centimeter scale avatar, which is then scaled up inworld within the avatar controller. During such operation, the bounding box doesn't scale down to centimeter scale because it's a geometry action from the skin, but since it is attached to the avatar, the bounding box gets scaled up along with the character skeleton to stay in the avatar controller. What effectively happens is that the final rigged item bounding box results to be 100 times bigger than expected, and therefore setting the low and lowest LoDs distances really beyond any meaningful viewing distance.

Please share what you think and, possibly, what your theories are about this. Hopefully @Beq Janus and @Vir Linden can look into it

This is a known issue that I reported https://jira.secondlife.com/browse/BUG-40665

There are two aspects at play here

1) a design feature

2) a bug

The design feature is that all rigged Mesh LOD is based on the bounding box of the avatar

Whilst in some ways this makes no sense (why should my bento rigged finger nails LOD decay at the same rate as my torso?) it also is what you want when you consider that you don;t really want your head to switch before your body, which if it were based on normal scaling is what would happen.

The bug is that the equation calls for the Radius of the BB to be used. but in Rigged mesh they incorrectly use the diameter. This doubles the effective radius used in LOD switch calculations which is why it is so far away.

you can barely see it but the LOW LOD model does switch in at about 60m when my LOD factor is set to the ludicrous 0.125 (the lowest possible)

At a normal SL default that would be 255m

March 5, 2018

So as not to get into the naming and shaming I have clipped this to the extreme. Enough that you can see the links.

The linked components are easily found by using the little navigation arrows just underneath the edit linked check box. Maybe there is a case for making those more prominent in t link set?

(note: they also work for select face. Ansa added those a while ago and I use them endlessly)

The root is a default block, full alpha and part way up the trunk.

The leaves and trunk/branches are separate meshes, as is the fruit.

At about 10m on LL defaults the tree vanishes

March 5, 2018

6 hours ago, Chic Aeon said:

Definitely thinking of you this morning when I was checking out a new venue about to open. The designer you referenced (not by name) in another thread was there. I tried to inspect the wares and -- like the car that I mentioned where you couldn't see any of the LOD info -- YOU
CANNOT SEE THE INFO ON THE TREE DEMO. The demo is no mod. The car was no mod, but that doesn't seem to answer the question as SOME no mod items (the matchsticks) you can see just fine.

I suspect that this is "partially intended behaviour" if you can have such a thing.

if you go into edit-linked, you should be able to cycle through the mesh components and view the LODs normally.

The reason I say "intended" is that I had to make a choice when I implemented, what do I do for a mixed object, Something made of prims/sculpts and Mesh. The answer I chose was to show a blank prim template which I believe was the legacy behaviour too. I am not convinced I got it right but I don't know what the correct behaviour should be. I'll happily take input and suggestions ideally via Jira for improvements (and I mean that sincerely). The code basically says "is this "a mesh" if so then show the details, if not do what it always used to do.

One thing I could in theory do, but I'm not sure how efficient it would be, would be to have a link set panel. The edit dialogue logic would then become:-

If we are a prim, we show the prim params

If we are a sculpt likewise with the sculpt map

If we are a mesh show the LOD info

If we are the root prim of a linkset.....show a summary of the links in the linkset. "This object has 4 components: prim: 2 sculpt: 1 Mesh 1" or something along those lines?

**** EDIT****

Ooops OK so I need to read further ahead or not post at 1:30am

so this seems to not be what I described.... As per Whirly's request. I'd be interested to see it.

The 2.3 weight on the server certainly supports the 4 prim claim.

March 4, 2018

On 02/03/2018 at 5:21 PM, OptimoMaximo said:

This occurrance is due to error accumulation in the floating point range.

Between a value and another, theoretically there is an infinite number of decimals, which a computer must round into value with a maximum amount of decimals (say, 6 numbers after the dot) in order to process them and give a result in a timely fashion.

Now, if the possible values range between 0 and 255 (X and Y axis sim dimensions are 256 meters) you have a limited amount of positional values that, at the scale end value, gives out a neglectable error by accumulation of the truncated values approximation. The Z axis instead has a cap of 4096 meters for prims, but there's no limit to the avatar position. Let's assume an height of 4096 meters, and the imperceptible error we had when we were within the "regular" 256 meters gets up to at least 16 times it previously was.

For my avatar, i came up with something that diminishes this effect, although it doesn't remove the issue completely. Hopefully mesh baking services will let us get rid of sliced avatars.

Basically it's due to the unused joints removal that the Bento project introduced, and you're slicing an avatar. If you make sure that each troublesome sections contain ALL the joints names of the old classic avatar joint list, as it was previously required, this gap effect almost vanishes.

Side note: this isn't an optimal thing for the asset itself, because you'd be keeping a lot of unnecessary data for a lot of pieces. You should manually remove the unused joints from each piece basing off their actual distance from the slice, and retain only neighboring unused joints.

Hi Optimo,

I had also explained the floating point error issue to @daFlesh as being the underlying cause of this issue, but I had never heard of the partial "workaround" you suggest. I'm really curious as to how this works. Are you effectively saying that bones that are referenced by the mesh but not weighted to ANY have a different impact than if those bones were unreferenced in the Mesh file? If I am reading this correctly too, the issue lies only with the original bones needing to be present and not the bento extensions?

I am no expert on rigged mesh (in fact someway towards the other end of the spectrum). I was under the impression that a vertex can have up to 4 influences only, though of course, each vertex may have a different 4 if it needs. It, therefore, puzzles me that the presence or not of bones that are unweighted makes such a difference. It seems to me that if we can find a way to demonstrate the problem fully then we can fix this part of the issue properly in the uploader or at least give far better guidance on the wiki as to why this needs to be so. Given that this issue only becomes evident as part of the cumulative quantisation error seen at long distances, it would suggest that the unused bones are still causing lossy quantisation, which, from my position of comparative ignorance, seems like a bug. Quantisation is an unavoidable feature of how things work, but this rigging issue ought to be fixable.

I am tied up on Fantasy Faire until April but I'd be happy to try to get a better understanding of this once the time crush is over.

March 1, 2018

On 16/05/2017 at 11:53 AM, Whirly Fizzle said:

I grabbed the free TPM male body & I can reproduce it.
I need to wait 24hrs till my inventory has synced to Aditi so I can test on older server versions there though.

The higher in altitude your avatar goes, the worse the problem is.
I see the joins in the mesh body have gaps too, not just the gap between the mesh neck and system head.

This looks like https://jira.secondlife.com/browse/BUG-9284 but I'll see if it reproduces on old server versions on Aditi once my inventory has synced over.

Whirly, if you get a moment, can you disable alpha rendering and check this again. Just want to test a theory.

February 8, 2018

1 hour ago, ChinRey said:

5 hours ago, Love Zhaoying said:

Would be nice if all objects started from a single parent had a “base” UUID so you could update them all via 1 UUID that way (scripts, etc.)

But they do! Thanks to Lucia Nightfire.

Indeed, they do have IDs , both the underlying mesh id and the "practically as good as unique" creation time but sadly that does not allow you to update them which I think was what Love wants.

It would be awesome to be able to say "replace all objects using the underlying mesh with this new one". I toyed with the functionality a bit in the reverse of that. I want to be able to compose a mesh so I can replace the Medium/Low LOD or more commonly apply a physics shape. I can probably do it in the viewer. I would pull the existing asset, apply the new LOD and reupload, but you'd be getting a new mesh asset (and a new upload fee). It is one of the "wouldn't this be awesome" building blocks to restoring more inworld building capability.

/me sighs at the length of her TODO/Wish list.

February 7, 2018

1 hour ago, Chic Aeon said:

Trees are the framerate killers

As they say in showbiz, "you ain't seen nothin' yet"

Forests of Animesh trees swaying in the breeze are likely to be "a thing". On the plus side, lower triangle count cos no alpha cycling, but the viewer will be doing a lot more transforms each frame too. It will be interesting to see whether there is a net benefit.

February 7, 2018

11 hours ago, Chic Aeon said:

I remember when mesh was VERY new. I went to a then very popular full perm mesh creator (furniture) and got one of the monthly group gifts. It was -- let's say a chair as I don't really remember and never used it. It came with something like FIVE 1024 alpha maps (likely AOs too but I don't really remember clearly) and ONE of them was the SMALL LEG of the chair.

I think that (with appropriate caveats) in general if I wanted full perm mesh I would also be expecting the maps in 1024, ideally an external link to the PSDs. If I provided template mesh I would probably do the same. That said...the examples that I provided I would ensure were appropriately scaled to the object to give the correct behavioural guidance. When I texture I tend to work at 2048 then scale down, so exporting those at 1024 makes sense. of course, most people will just use them as is, and again we come back to education and incentivising good behaviour.

3 hours ago, Chic Aeon said:

What I uploaded just now is about as good as I can do at the moment -- or perhaps it would be more correct to say "the choices that I am MAKING at the moment" , so wanted to post with a bit of explanation for new mesh makers and maybe NOT so new ones that just haven't tried to make "game asset" meshes.

I like the choice of words. I've been variously accused of "dictating" good behaviour and best practice and I try to be quite careful with my words because I am not anything special when it comes to design and artwork. I give advice on what I have learned on my own journey and that really is all that we can do. I am constantly learning new things, it is really what keeps building in SL interesting. In a lot of cases when I blog or write things down in other places it is as much for my own use in clearing my ideas from my head.

Sharing our journey and tips is what SL was built upon.

February 7, 2018

8 hours ago, arton Rotaru said:

And 2 materials even. Lets hope these are mapped onto a texture along with some other stuff at least.

This is the thing that the tools tend to be bad at reporting. a 1024 on there is a lot more legitimate if it is the same texture sheet being used on all the rest of the clutter. Baking complex scenes into a single sheet and reusing that sheet is an important technique. What we probably ought to have in the tools is something that says "object uses 15 instances of textures consisting of 2 unique UUIDs" or something like that.

February 7, 2018

9 hours ago, Chic Aeon said:

Want to be fair though. I was over at Babbage last night taking a photo for a blogger meme thing and found one of the only mesh buildings there (I found two) had zeroed out all but the top level. Amazingly it was SO LARGE it actually worked well there. So sometimes very odd choices can be OK in CERTAIN situations.

yes... that's actually why I try to stay out of the witch hunt type aspects because there are legitimate reasons. The LOD calculation actually caps at 256m IIRC, so once you hit a certain scale the lower LODs will never show. In those cases, you can argue that zeroing the LODS that cannot ever be seen is correct as it reduces the overall asset size. That is one of the edge cases though and one reason why the lab will always struggle to come up with a new equation that fits, there are just so many different uses of their technology.

I hope you never found my buildings :-) My Babbage builds are always on my list of rebuilds and never quite reach the top.

Quite a lot of Babbage is mesh. Victor's builds are all meshed, mesh studio creations typically, then Hattie Panacek's buildings get used a lot.

February 6, 2018

On 04/02/2018 at 11:13 PM, Chic Aeon said:

I actually made LODs for this big model as it was "organic" and not what I normally do. Making the custom LODs was a very good thing in this case (and in a couple of others today) as again, very organic (won't show as I think Fantasy Faire is supposed to be secret LOL).

Anyway even using the exact same files WITH my own custom LODs I ended up with a higher land impact and cost on Agni than I did on Aditi. I had previously thought that the Aditi uploader and the Agni uploader just weren't in agreement on things when THEY figured out the LOD models. That doesn't appear to be the case.

That's a thread I have yet to come back to. I think I can answer some of your issues there are I would love to explore that more once I can stop ducking the meat-cleaver wielding assasins that are on my tail these days :-)

February 6, 2018

On 04/02/2018 at 11:22 PM, arton Rotaru said:

Smells like an issue with the new Firestorm viewer. This thing on the picture has 39.752 triangles in it's High LOD. 8 LI seems kinda low for that number, and indeed, it's lowest LOd has just 19 spikey triangles all over the place.

The 72 in Callum's post might well a mini-bug (see my post above), I cannot reproduce it, I suspect a glitch during the loading. The object overall is indeed 39K triangles and it is composed of 7 parts. The LI of 8 is what it is, that's got nothing to do with Firestorm, the object is constructed of 8 separate parts none of which have a BB larger the 1.6m, it doesn't make any specific tricks. It is a common (overly dense) model which happily does not cheat the LODs to keep the LI lower but accepts the higher LI. This item could be made a lot lower LI than it is, but at least it does not scam the user by asking them to hijack their debug settings to make it "look right".

February 6, 2018

On 04/02/2018 at 10:49 PM, Callum Meriman said:

Is it a real bug, or just something displayed in the incorrect spot?

To me, for the way the LOD numbers are, 8 LI is just too high.

Edit: This object is for sale in the current Fameshed if the more knowledgeable wish to check.

There's a mixture of issues here.

1) I think we have a small bug, where the 72 is an incorrect display in FS, clicking away and back again will almost certainly fix that, but if not I would be interested to see as I have never managed to see this except with occasional glitches when a mesh first loads. It might be a side-effect of #2 below.

2) Is a "feature" of the way I display linksets. I'd like feedback and suggestions on what the right option might be. The object is a 100% mesh link set, the root prim is a 2 triangle floor, the actual LOD info is 2 2 2 1. the rest of the LODs parts are constructed with solid high-poly LOD models and the 8LI reflects that. When you edit a multipart object it should just grey out the info panel I think, there is no sensible way for me to display such an object (it might be composed of prims and mesh or even sculpts), so it should probably keep the right-hand panel blank. the correct behaviour does happen when you "edit-linked" you can then use the small arrows or simply click around, to examine the individual components. I'd be happy to hear thoughts on what that initial (top level linkset) display should look like.

In the animation below you can see the outline in yellow, of the root prim.

February 2, 2018

4 hours ago, ChinRey said:

I asked a Linden about it a while ago and that is pretty much what he said too. But it's very unlikely any upgrades will affect existing content. They would have to re-parse every single mesh asset already in the database for that and that would be a huge and completely pointless task.

I actually suggested a re-parse (slight tongue in cheek) recently and the response was "we don't touch legacy content" so you are safe :-)

February 2, 2018

On 31/01/2018 at 7:59 PM, ChinRey said:

Right now I'm glad I'm not a Linden because if I was, my poor avatar would have had to wear Shrek ears for at least a month. I forgot to sort the vertices and of course the uploader will only keep a loose one if it's no. 1 on the list.

Anyway, it's all my fault. Thank you Arton and Aquila for helping me figuring it out!

Interesting, it is an anomaly that this works at all. I'm not about to poke it and find out why, but given that the DAE loading code is a horrid mess and well overdue for a rewrite, don't be surprised if this does mysteriously stop working at some point. I've always padded with a tiny triangle, I'd never thought about this.

What are the typical use cases for this? I can see two primary ones, are there others?

1) Boosting the bounding box on small items to increase visible range (at the appropriately higher LI cost of course)

2) Offsetting the centre of rotation

If I hear of any rewrite work, we can have the discussion with the Lab as to whether this is a practice that needs to be supported or left to die. Of course, the correct solution, assuming the two use cases above are the main/only ones is to allow arbitrary scale and offset of the BB on upload. I had a quick look at this once, but "ugh code smell" maybe we'll have to revisit it.

January 30, 2018

4 hours ago, Chic Aeon said:

How do you designate a different texture for the lower LODs? I remember LOTS of chatter on this when mesh was new and having a different texture for each LOD setting which at the time seemed to not be a good idea but they were talking about simpler objects on the whole.

While Aquila makes her pretty illustrated explanation which I am 99% certain she is doing ;-) the answer is quite simple. have a single hidden triangle in each of the non-imposter LOD models that holds the imposter texture.

Thus the window might have 2 materials as a model, add a 3rd material and assign one triangle only, keep the triangle hidden (scale does not matter). When you create the imposter LOD models, you have the opposite task. You will need to retain 2 tiny hidden triangles for the original modelling materials and then the 2 large triangles for the imposter rectangle.

January 30, 2018

7 hours ago, Callum Meriman said:

Just to be clear I wasn't picking on that home creator, he does beautiful homes, This tool has just been a huge eye opener to me, along the same lines as complexity was to my outfit. I could have also used this other item that has used LOD abuse, a Chestnut from the number one garden shop in SL (unnamed). More than 12 metres and the trunk disappears. (I coloured the link purple, but the rest of the trunk is the same, zeroed out LODS)

And I think that is the point. This was never meant to be a witch hunt. There are good reasons for zapping LODs, there are also bad reasons. As a designer, we have to consider where our items will be seen from typically and what the expectation will be. then we can choose whether to invest time and LI in the LOD models. These new tools were all about giving back some of the inworld building experience that, as builders, in particular, we lost with Mesh, letting us see our creations without fiddling around, and to find out how they will look to others as well.

Forums

Blogs

Knowledge Base

Posts posted by Beq Janus

Linden Lab

Tilia

Second Life

Connect With Us

Partner With Us