SVG Support In SL?

[Lizzy Reikaz]

For those who haven't worked with them, SVGs are vector images. Something that can be scaled up any size without losing quality while also being VERY small in file size.

I would LOVE to see SL support them, especially for HUDs.

Even if the underlying tech of converting the SVG to a Bitmap remained, the storage and transport of SVGs to clients would be so much faster. At well, when rasterized, it could be scaled to a size that works well for the host machine.

If SVG rendering was natively supported though... I think we would see an immense performance improvement for HUDs and signs. 

Is this more of a pipe dream, or could it happen?

[Alwin Alcott]

3 hours ago, Lizzy Reikaz said:

For those who haven't worked with them, SVGs are vector images. Something that can be scaled up any size without losing quality while also being VERY small in file size.

I would LOVE to see SL support them, especially for HUDs.

Even if the underlying tech of converting the SVG to a Bitmap remained, the storage and transport of SVGs to clients would be so much faster. At well, when rasterized, it could be scaled to a size that works well for the host machine.

If SVG rendering was natively supported though... I think we would see an immense performance improvement for HUDs and signs. 

Is this more of a pipe dream, or could it happen?

create a feature requeat Feature Requests | Second Life

[Zalificent Corvinus]

16 hours ago, Lizzy Reikaz said:

Is this more of a pipe dream

BINGO!

 

SL uses ONE texture format, internally, JPEG2000, one of the WORST image file formats ever invented. Changing to allow other formats would mean gutting the server code, and the viewer code, break EVERY TPV in existence, and that's 70% of the userbase right there, and require messing with petabytes of stored assets, adding flags to tell the software that an asset is not an SL-Standard image, but something else.

 

It would probably cost millions of USD, and take months, if not years for LL to make a mess of it's launch, and all so a small number of "graphics design" students can mess about with vector graphics images.

 

[Lizzy Reikaz]

4 hours ago, Zalificent Corvinus said:

 

It would probably cost millions of USD, and take months, if not years for LL to make a mess of it's launch, and all so a small number of "graphics design" students can mess about with vector graphics images.

 

Isn't something like this necessary to bring SL into modern times? A total rewrite of a lot of the code?

 

My understanding is that they want it to persist.

 

I wouldn't undersell SVGs. If we had them, I think a majority of HUDs would use them.

 

As an aside, if web views in the HUD didn't break on sim crossings, we could just use them. Not sure how hard it would be to decouple the web session from the sim and make it a centralized service.

[Zalificent Corvinus]

6 minutes ago, Lizzy Reikaz said:

Isn't something like this necessary to bring SL into modern times? A total rewrite of a lot of the code?

They tried that, it was called Sansar.

6 Years of wasted time, effort, and money, making an unfinished system most SecondLifer's didn't want to use, with a dreadful render engine, bad avatars, and  then they sold it.

Based off the number of staff involved in that fiasco, and typical Silly-Cone-Head Valley wages, they probably dropped 50-70 MILLION USD on that fiasco.

 

Re-writing a system from scratch is slow and expensive at the best of times, when done by a real software developer, done the way LL usually do things, by the time they get a BROKEN version of SVG into the platform, it will have been universally deprecated and nobody will still use an image editor capable of exporting it.

 

14 minutes ago, Lizzy Reikaz said:

My understanding is that they want it to persist.

Shutting a system down for a few years while you rebuild it is NOT how you get it to persist., you'd lose most of your already niche market customer base and go bankrupt.

 

 

[Lizzy Reikaz]

31 minutes ago, Zalificent Corvinus said:

Shutting a system down for a few years while you rebuild it is NOT how you get it to persist., you'd lose most of your already niche market customer base and go bankrupt.

Do you think improving web views on prims so they work cross sim is doable?

 

Because then we would have access to SVGs and many other things.

[Zalificent Corvinus]

4 minutes ago, Lizzy Reikaz said:

Do you think improving web views on prims so they work cross sim is doable?

Doable? Maybe, advisable, not really. It's a lot of extra work for something most people don't really give a damn about.

MOAP is a clumsy kludge, and for a company with a very limited pool of dev staff, and a limited dev budget, it's not worth the waste of time that could be better used on things that actually matter to most users.

One of the most hated HUDS in SL, uses web based media, but you seem to think that most SecondLifer's will share your obsession with SVG's. Most people in SL would rather have less laggy rendering, or better region crossings that muck about trying to convince everyone to remake all their HUDS with the vector based output of some graphics design students with time on their hands.

The only use most MOAP using people in SL have for MOAP is watching pron, on Prim TV's in their skyboxes.

Is it worth improving?

I don't see it my self.

 

[Lizzy Reikaz]

56 minutes ago, Zalificent Corvinus said:

but you seem to think that most SecondLifer's will share your obsession with SVG's.

Woah now... No need to be on the attack...

I like we views as a HUD because I can write a system in JavaScript, have access to HTML and CSS - allowing me to make much more complex interfaces that are still very smooth and fast.

The web viewer in SL supports ES6 and modern CSS.

And it's pretty easy to hook up LSL to communicate directly with the JavaScript.

[Qie Niangao]

I had to test to make sure there's not some weird problem but no, the <svg> tag works just fine on a MoaP surface, so I'm not sure what specific improvement to MoaP is being requested here. The real problem with MoaP is privacy, and unless somebody trusted (e.g., Linden Lab) is willing to host some sort of proxy/relay arrangement—that is, as long as the MoaP script is presented with an IP address uniquely associated with an avatar—there will be widespread reluctance to use it. (Historically in SL, the "redzone" problem.)

That does not mean SVG is completely off the table, though, as one possible approach to addressing the ridiculous complexity of drawing text (specifically) on surfaces. That problem comes up occasionally at the Simulator User Group so there are probably feature requests on record about it. As I vaguely recall, SVG wasn't the frontrunner for how to proceed, but a relevant Linden-submitted feedback issue is under review.

[Lizzy Reikaz]

@Qie Niangao yeah that does work, but I agree there are a lot of issues with MoaP.

- as you said, security. 

- when you cross a sim, it breaks and needs to be reloaded

- the"background" of a MoaP is white, not transparent. (This just needs to be changed. Just like the link you posted, it should be up to the user to provide a background, or using CSS to define a background on the HTML side)

If they allowed the client to make the connection, I think it would fix a lot of the issues.

Pros:

- said security issue is fixed

- could work cross sim

- faster?

Cons:

- what you see would longer be synced with other players (a non issue in HUDs, and this could actually be a good thing in certain applications)

- I'm pretty sure JavaScript already executes on the client side, so I don't think there is any increased fear of malicious code.

That does still leave an issue with

llRequestURL

As this essentially creates a web server. Though I would imagine most computers could handle a simple web server to serve files locally. It's just the infrastructure of creating this system locally that is needed. And this would also allow for cross sim travel without reloading.

[Qie Niangao]

Yeah, for the MoaP surface to do http with a script, it's stuck with ephemeral URLs that poof at region borders. But apropos the start of the thread, a script can still paint (and repaint) static svg on a MoaP HUD, a la:

string html="<!DOCTYPE html><html><head><meta charset=\"utf-8\">
<html><body><svg width='100' height='100'>
  <circle cx='50' cy='50' r='40' stroke='green' stroke-width='4' fill='yellow' /> </svg></body></html>";
integer MEDIA_FACE = 4;

default
{
    state_entry()
    {
        html = "data:text/html," + html;
        llSetLinkMedia(LINK_THIS, MEDIA_FACE,
            [ PRIM_MEDIA_AUTO_PLAY, TRUE
            , PRIM_MEDIA_CONTROLS, PRIM_MEDIA_CONTROLS_STANDARD
            , PRIM_MEDIA_CURRENT_URL, html
            , PRIM_MEDIA_HOME_URL, html
            , PRIM_MEDIA_HEIGHT_PIXELS, 256 
            , PRIM_MEDIA_WIDTH_PIXELS, 256
            , PRIM_MEDIA_PERMS_INTERACT, PRIM_MEDIA_PERM_ANYONE
            , PRIM_MEDIA_PERMS_CONTROL, PRIM_MEDIA_PERM_NONE
            , PRIM_MEDIA_FIRST_CLICK_INTERACT, TRUE // if only
            ]);
    }
}

which shouldn't have any trouble crossing region borders or anything, but still depends on the user having media enabled. (It's a quick and dirty example, but you get the idea.)

[Lizzy Reikaz]

@Qie Niangao thanks! 

I think the way this worked made sense 20 years ago, we just have better tech now.

 

From what I see, most server based games try to split their systems apart instead of how SL is tightly coupled.

[Gabriele Graves]

Just be aware that there's no guarantee that everyone would be happy to use a MOAP HUD.  Some people have that turned off and don't want to turn it on.

[Lizzy Reikaz]

8 hours ago, Gabriele Graves said:

Just be aware that there's no guarantee that everyone would be happy to use a MOAP HUD.  Some people have that turned off and don't want to turn it on.

Imo, they should have a seperate "play media" option for huds and for the world. I can fully understand why people turn it off for the world.

[Fraser Lisle]

7 hours ago, Lizzy Reikaz said:

Imo, they should have a seperate "play media" option for huds and for the world. I can fully understand why people turn it off for the world.

It's also just plain buggy. I have a few MOAP HUDs that need a lot of coaxing to even work, often have to manually start them to get them to load.

 

I certainly don't really like it being used for HUDs but it does make sense for a lot of them, it's just not very well implemented imo.

[animats]

I've brought this up at Creator User Group, but reaction from Lindens was mostly negative.

It's not that hard to do. We'd need a SVG interpreter in the viewer. Those are available open source. They're much smaller and simpler than a web browser. Probably Tiny SVG 1.2, which is for dumb phones, would be enough. That's enough for signs, HUDs, control panels, and such.

Scripts would attach SVG to a face of a prim by sending it a string, not a UUID or URL. That allows dynamically constructing SVG, so you can change signs, move meter pointers, and make live HUDs from an SL script. It's a minimal ability to draw things in world, not a replacement for images. The limits on string length prevent overdoing this.

[Qie Niangao]

6 hours ago, animats said:

The limits on string length prevent overdoing this.

Although string storage is only constrained by script memory, some functions limit string parameters to 1024 characters, which would be pretty minimal SVG, but maybe enough for its intended use in SL, not sure. Or a more generoous limit could be imposed on the RenderSVG function.

[animats]

8 hours ago, Qie Niangao said:

Although string storage is only constrained by script memory, some functions limit string parameters to 1024 characters, which would be pretty minimal SVG, but maybe enough for its intended use in SL, not sure.

That's the idea. It's for text, changeable signs, HUDs, and control panels.