Upgrade lilToon from XSToon

[kazu0617]

Is your feature request related to a problem? Please describe.

It's a bit of a blown idea, but given that XSToon has already stopped updating for more than two years, we might as well discuss this approach.

lilToon is also commonly used on other platforms and licensed by MIT, so it wouldn't be too hard to incorporate.

lilToon is here:

• Main Website
• GitHub

Describe the solution you'd like

Just as I once updated from FlatLitToon to XSToon, I embed the code to convert from XSToon to lilToon in the source and change it to work with lilToon.

I'm sure there will be some visual problems, but since it already supports linear, it may be a somewhat useful idea. It also gives you more control over the look than XSToon, and it solves the challenges you want from different Toons.

Describe alternatives you've considered

Mod ... It can't. It's too expensive to develop, and there's even the risk of a crash if it's broken up for each user.

Additional Context

Another point of view is that the technical debt may be less if you adopt and then update shaders that the author is actively developing, rather than continuing to adopt shaders that the author has already stopped updating when updating the rendering engine.

[ZarosTenjin]

This has been covered in Geenz' Office Hours. The plan is to replace Xiexe with their own custom toon shader.

full recording can be found here: https://officehours.probableprime.co.uk/episodes/geenz-2023-10-11/ Excerpt from the captions:

474 00:26:02.270 --> 00:26:04.000 Um That being said, Zig Cy

475 00:26:04.109 --> 00:26:08.280 is definitely on the list of shader that's probably getting removed at some point.

476 00:26:08.290 --> 00:26:11.670 And instead we're gonna be replacing it with our own tune shader

477 00:26:11.890 --> 00:26:15.579 uh which will include uh some additional features that we just

478 00:26:15.589 --> 00:26:18.300 don't really support or is well supported in the current version.

[SUPTECGourry]

My main concern is whether the "next" toon shader on the future render engine will be implemented appropriately with all the features requested. I remember on the old platform; people almost had to put everything on fire and make a lot of noise to get matcaps implemented. It was not implemented before with the "excuse" of "no one wanted/requested." we are still missing a lot of "basic" features of most common toon shaders like texture/matcap masking.

[ZarosTenjin]

My main concern is whether the "next" toon shader on the future render engine will be implemented appropriately with all the features requested. I remember on the old platform; people almost had to put everything on fire and make a lot of noise to get matcaps implemented. It was not implemented before with the "excuse" of "no one wanted/requested." we are still missing a lot of "basic" features of most common toon shaders like texture/matcap masking.

I find that mindset absolutely misplaced. You have the Github for feature requests like these, but that does not mean that there will be a guarantee for any feature to be implemented. It is at the digression of the developer to make the call which features make sense and which not.

Entitlement is no good.

However Geenz mentioned in the same office hours how shaders are planned to be interacted with through/made with protoflux so if you have the knowledge or know someone with said knowledge expanding the functionality of a shader will be easier in the future. Its in the pipeline but they're not there yet.

[Konshu]

While this is a sensitive topic across many creators, I think a productive conversation would be around what exactly do you want as features to work within Resonite? Stating shader names doesn't really provide what needs end users actually are looking for beyond the existing PBR and toon shading. This also might uncover some knowledge gaps when it comes to community understanding how to effectively use the shader technology and their desired results.

[kazu0617]

While this is a sensitive topic across many creators, I think a productive conversation would be around what exactly do you want as features to work within Resonite? Stating shader names doesn't really provide what needs end users actually are looking for beyond the existing PBR and toon shading. This also might uncover some knowledge gaps when it comes to community understanding how to effectively use the shader technology and their desired results.

Of course, that point of view is important, and in that sense, I am putting "a blawn idea" at the top of the list. However, it is a fact that liltoon is always used for avatars sold in booth. Also, the fact that each value has to be re-converted when bringing those avatars (and if it is a standardized thing like VRM, it does not follow such a standard either) is a headache for newcomers, those who are thinking of migrating, and those who are playing between Resonite and the rest of the world. It is also a headache for those who want to come to the market, those who want to migrate, and those who are playing between Resonite and other worlds.

So, just as we replaced the "toon shading" base from FlatLitToon, the idea is that we might as well replace it again now. If it has never been done in the past, but since it has been done once in the past.

[Geenz]

We're not taking this one on since we intend to completely replace Xiexe with our own toon shader (for eventual IP and porting to Sauce reasons).