Add "Keep Low Rez" or "Hexagon" option

As you know as circular and spherical objects are reduced into hexagons when they are at a distance based on size and distance from you.

I propose that a flag be added to lock them into that lower rez mode, thus creating a new prim type that would take less tris to render.

I have tried to convert my ”pose balls” to “pose cubes”, however it looks strange.

Note: This would not allow you to texture each facet since it would still be textured as if it was a sphere or cylinder.

You might be able to get the same effect by adjusting your Graphics settings. Go to preferences, then the Graphics Detail tab and look for the Object Mesh Detail slider. Put it all the way to the left and all objects will be rendered with less detail - even when you get close.

-edit
Well, I just checked this out in-world. Objects stay in their lo-res versions until you get within a few feet, but then switch to a more detailed version - at least on my machine. /shrug

Hmm, using LOD to create 'new' shapes, that's a really interesting idea!
It would also allow you to optimise a build where some details are never really going to be seen, thus allowing the LOD system to skip over objects that are already at or below the level it would want them to be (ie if you're zoomed in LOD would be 1.0, since you set the object to 0.2 it would just ignore it and leave it alone).

Cool and handy for optimisation, I like! Plus if LL add more object detail later they can always adjust LOD to use a maximum greater than 1.0 (e.g if they double the detail per prim they can have it go up to 2.0).

I like this idea on the grounds that it reminds me of something I used to do: when I made electronic music, I used a bitcrusher to alias and make really glossy, pristine stuff sound like lo-fi crap. It just had a CHARACTER to it.

I used to call low LOD "hexagon donuts syndrome". So I totally smiled when seeing this thread. Using this "downgrade" as a controllable per-prim basis would have some very cool usages. Off the top of my head, even a LOD pop-up menu where you could select, relative to the ceiling you have set as a detail slider.

I mean, hot damn, "CRUSH THAT SPHERE INTO A HEXITHING!"

I don't know how possible this is, but I'd start by using a Feature Vote Proposal and getting lots o' support from friends and strangers-to-become-friends for it.

I've created a vote

I'll Edit this when done

That's strange I get a blank page and the vote does not show up.

I tryed again and nothing...

---
Then again I am hopeing that this is a simple enough feature to be added in next time they work on that section.

Do you have any spare votes to create it with? You must have at least one to create a new proposal, I'd create one for you but I have none either

Nope, I still can't propose the vote.
I'm using the latest version of Firefox and I tryed disabling the firewall.
I have 10 votes, but I still get a blank page after hitting the "Create propsal" button.

Here is what I am planing on proposing.

PLEASE if you do create a proposal make shure it is done right.

---
Catagory: Building --- Primitive types
URL: /13/e8/111546/1.html
Name: Limit LOD or "Hexagon" option.

As you know as circular, spherical and toroidal objects are reduced into hexagons by the LOD system when they are at a distance based on size and distance from you.

I propose that a setting be added to lock them into this lower-rez mode, thus creating a new prim type that would take less tris to render.

Note: This would not allow you to texture each facet since it would still be textured as if it was a sphere or cylinder.

This could be as simple as “Hexagon” or more flexible as “Polygon segment Count”

Some searching for existing proposals...

New prim types, Hexagon, Polygon
https://secondlife.com/vote/index.php?get_id=1168 16 votes

Inclusive
https://secondlife.com/vote/index.php?get_id=318 179 votes

Sortoff, but the other direction
https://secondlife.com/vote/index.php?get_id=202 31 votes
http://secondlife.com/vote/index.php?get_id=49 611 votes W reply

In a way setting a sphere to a 8-sided octagon would be like chamfering a cube, but a lot less complicated or flexable.

Is it possible to chamfer a cube without using multiple prims? Or do you simply mean, using multiple prims to create a camfered cube?

I want to make an emerald cut stone. I made a big one thinking I could shrink the object, a simplified one at that (only one bevel layer each for top and bottom). Took 14 prims, and now I can't shrink it! (Anyone want a 2' emerald? lol)

I guess a texture is the way to go, unless there really is a way to chamfer a cube. (Hopefully not just 45 degree cuts, too.)

He means using 1 prim, which is not currently possible.



You can't shrink it because one of the lengths of your prims is already at minimum. try increasing the thickness of each facet.
And why would you want a 14 prim emerald anyway? It's like a guy who said he modeled the rivets on his robot avatar.
Rivets! As prims! Honestly...

There are a variety of tricks to making super-small prims, by starting with standard size (half meter) prims and cutting them down using path cuts, profile cuts, and hollows until you have just tiny chips left of the original prim... building with them, THEN shrinking them to the final size.

I think a max lod setting for prims is a wonderful idea. For the already mentioned reasons essentially creating new prim types using lod, for two more reasons.

Additional Reason #1:
Most of the framerate drop I get seems to be from update geom, which in turn seems to come from prims switching level of detail. If this could be prevented, even if just on my own builds, I would love it.

Additional Reason #2:
This is sort of related to new prim times. One of the annoying things about creating detailed builds is that matching edges always show a seem because prims in one link set don't change LOD between the same frames. So one prim butted up against another might switch to a different poly count and for a second or more, the seam is glaringly obvious. This could be avoided if the prims were forced never to change LOD. It won't work on objects you want more detail on of course, but a partial solution is better than none.

Edit: I've created a proposal to this effect:

http://secondlife.com/vote/get_feature.php?get_id=2646

OK, the problem with a "max LOD setting" for prims is that you would need to store the information about the LOD setting you want in the prim. The current limitation for adding new features to prims is, apparently, finding places to store them without breaking existing prims... even storing the fact that a feature is enabled. This is why some of the changes over the past year have led to a loss of precision in some fields... LL is using the bits that were previously used for that precision for other purposes.

So it wouldn't be any easier for them to implement a "low detail" bit than to implement a "hexagonal prism" prim type... and the latter would be less likely to break in future updates if the LOD algorithm changed.

I think there are only about 4 levels of detail being used for each prim, which means it would require 2 bits.

Currently the number of bits that can be used to hold prim information is very limited because LL implemented their own protocol on top of UDP, making it easier to send updates that will fit evenly inside a single packet. That protocol is slated to be changed over to something a little more proven and a lot more flexible as stated by I "think" Cory Linden in the technical town hall.

Even if the protocal remains unchanged, 2 bits is a small enough requirement for a large enough addition that I would at least like them to take it under consideration.

For now assume it's technically feasible and let a dev shoot it down if it's not.

Even if this was a good idea, we have already had path cuts reduced in resolution to scrape individual bits out of the format. But it's not a good idea, because it locks today's particular implementation into place. If they want to change the LoD settings to allow for more levels of detail, or to allow for a power-of-two scale, that would break all the content that used "LoD locking".

Well, first, this is irrelevant. If they change the prim formats to allow more room it would *still* be better to implement changes that are less dependant on the current technology. Bit it's a *lot* more complex than that, and packet size is the least of the problems. Prim updates are incremental... if you only change some attributes of a prim you only send part of the prim's parameters... so they aren't packed evenly in a packet. The main reason is compatibility with the existing prim storage format.

IF it's technically feasible, then so is using the two bits for any other purpose... and using them for this purpose would prevent them from being used for something else, to (for example) increase the number of prim types, or add a "bend instead of twist" option.

You're first point is a good one. It would essentially lock the number of LOD levels to however many there are now, or risk breaking things later. But if someday they decide to change the number of Levels of Detail, then it's a large enough update the risk is there for breaking content anyway, and the Max LOD parameter can be redefined or updated on the fly to work with the new paradigm. Or alternatively, instead of only allowing 2 bits for 4 Levels of Detail, you could make it 4 bits to allow for 16 Levels, which I think might be excessive but would allow for larger precision behind the scenes for future updates. and 4 bits is still smaller or comparable to the requirement for a floating point parameter like for instance bend.

Second point. That would be a partial update versus a full update. partial updates are not a problem, but it is relevant to consider how large the data for a full prim update is. That is a limiting factor on what kinds of parameters can be added to prims. Without knowing the existing prim information format, I can't definitively comment on maintaining compatibility, but I imagine it's a serialized structure, in which case adding a parameter is pretty straight forward, if tedious because of probably having to update the prototype in several places. Heh, and projects this large with this many people working on it for this long are never that clean and simple so yes, like most updates to SL, it would be a bit of work. So, I guess good point on an additional hurdle.

Third point. You're right, if you're going to do one update, why not do another? like adding new prim types. Well, because while adding more prim types does by definition allow for more prim types , it doesn't provide any of the other advantages, like quicker rendering. I also still think, in spite of point two, that implementing a LOD limit would be easier than implementing a whole new prim type or types, and a bend option or any other floating point parameter would require even more cramming and rearranging of the prim information format.

So, to sum up:

I think that if the number of LOD levels change it's a large enough update that it's in danger of breaking content anyway, and a solution could be put in place to update prim parameters when an object is used after that update, in an intelligent way.

I think it would require some work to implement this, but less work than adding new prim types or parameters with a higher lower level of granularity, and it gives some added benefits above and beyond those anyway.

I think that if my own estimation is correct, it would be worth the trouble, and personally I'll wait for someone who knows the code base to say otherwise. Feel free not to vote for the proposal .

It's not just changes in the number of levels, there's changes in the way the levels are defined. Right now the lowest LOD for a cylinder has 6 segments. If for some reason they needed to change things so the lowest LOD had 4 or 8 segments (say, it turned out to make some graphic optimization on newer graphics cards possible), they wouldn't be able to.

But it would only take one bit for a parameter that says "instead of applying the 'twist' parameter to a rotation of the profile about the axis, apply it to a curve in the path". So you could have twisted or bent prims, but not both.

A full update transmits much more than just prim geometry: it transmits particle systems, textures, colors, text, sit targets, flex and light lists, and so on. It doesn't fit evenly into a packet even now, and prim geometry is such a small part of it that the impact of changes to the geometry on network are simply dwarfed by the impact of changes on prim storage and compatibility with existing prims. Anything that changes the size of prim geometry would require defining a whole new set of prims and leaving existing prims as a kind of compatibility mode. They've already been through this process once before.

The prim geometry is a packed structure with no internal serialization information.

More 'if you're going to do an update, and you can only do one, then it's better to do one that doesn't lock an accidental implementation detail in as part of the API'. I've seen this kind of decision blow up over and over again during the past quarter century (which is how long I've been a professional programmer).

That way lies the y2k bug, the y2038 bug, buffer overflow attacks, cross-site scripting attacks, and people with funny characters in their names being erroneously left out of paycheck runs or sent to jail because they got put in the wrong list or not put in the right one.

They have changed the LoD behaviour in at least half of the updates... major OR minor... since I've been in SL.

There is no chance that this would ever be implemented, and if it was it would cause problems within a month.

Alright alright you win . I wasn't aware that LOD implementation had changed recently or frequently. I know what a full update transmits but I still thought fitting it all into one packet was a significant current design limitation. The one reason i really wanted it was to improve performance without having to lower the LOD of everything (object detail slider). I guess I'll just have to wait for further improvements to the LOD algorithm or until everyone has hardware fast enough that it's no longer matters.

btw, how do you know what the implementation of a prim update is? is this some some technical documentation I haven't seen?

What I've gleaned from discussions on this board, from postings by Lindens (particularly comments on what they had to do to change the way taper worked to make flexiprims practical without breaking existent content), and from having to perform similar hacks myself over the past 20 or so years.

I just remembered that I've got a vote out for the "bend" option: Prop: 1952 - New prim types or features for large curves...

This would only require stealing one bit from the prim geometry.

I'll bump the feature thread.