Jump to content

Vertex Color shading for mesh objects


You are about to reply to a thread that has been inactive for 76 days.

Please take a moment to consider if this thread is worth bumping.

Recommended Posts

I think the SecondLife user experience would benefit from supporting Vertex Shading because it would ultimately lead to performance improvements where taken advantage of.

What is Vertex Shading?

Vertex Shading is a method of shading an object. Each vertex (A point on the object) is assigned a color, a smooth gradient of color is formed from one vertex on an object to the next

https://www.panda3d.org/manual/images/8/8a/Cg_tut_cube1.png.

An example of Vertex Color Shading. Each Vertex (Corner) is assigned a different color.
The Colors are smoothly blended across the face.

The color will tint the texture if the object has a texture, the same way that we can currently color an object inside SecondLife.

How would Vertex Color Shading lead to Performance Improvements?

Texture memory is a limited resource that frequently causes lag in SecondLife.

By allowing a creator to tint vertices, a creator can re-use textures in areas where otherwise they would not. In some cases, where a creator does not need texture, they can replace the need for a texture entirely.

For example, throughout a mesh house, the floor might use the same planks material, however a creator would use a separate 1024 texture for every room because every room has a different shape with different ambient occlusion and shading characteristics.

By using vertex colors, a creator would be able to re-use the same material in every room, and use vertex colors to recreate ambient-occlusion effects and other special shading characteristics, saving large amounts of texture memory and in turn allowing SecondLife to run faster.

How would it be implemented?

Vertex Shading is nothing new and many game engines use these.

The standard mesh format we use to upload (Collada .dae) supports vertex colors and most 3d modelling software Blender etc support  Vertex Colors.

It would simply be a case of the viewer using the data that is already there, to tint the object.

If you have 20 minutes, here is an example of a guy using vertex colors to color a castle object. He does not use any textures at all, although I envision creators would still use textures in SecondLife. What caught my interest was at 13:50 where he starts using Vertex Colors to add AO effects to the object.

Thats it :)

I don't know if this would actually improve performance. I suspect it would for the reasons I outline above but I'm not an expert. Let me know what you think.

 

  • Thanks 1
Link to comment
Share on other sites

Posted (edited)

image.png.76102d41ce76af1fe4346f4ae5e23543.png

This castle is colored and shaded using vertex colors. Some vertices are given darker colors to give an ambient occlusion effect.

If we imagine how we would texture this castle in SecondLife with a brick effect, we would use many different brick textures to support the different shapes around the castle with different ambient occlusion and colors. However using Vertex Colors, we would be able to use one tiling brick texture, and still have ambient occlusion and color variation by using vertex colors.

 

This could also be used for adding color variation to other things such as grassy fields etc. Just some ideas.

Edited by Extrude Ragu
  • Like 1
Link to comment
Share on other sites

This wont do anything for performance .. 

BUT ! as a replacement for solid tinting if it could be done in the viewer, it would make fitting objects to the style of a build / each other much easier.

There is a reason SL rocks the white painted shabby chic look - it's easy to put objects from different creators side by side and not have them look out of place. A basic tint can help (shakes fist at no mod stuff), but vertex colors would be even better - even if done in a simplistic way where each face had 2 assigned tint colors and the end user could change them.

This would be a nice replacement for tinting, especially if it could be made an always-mod property - that is a property end users could always change regardless of the mod status of an object.

Link to comment
Share on other sites

All i see is more baked AO.

AO baked into the vertex shading, AO baked into the texture. Realtime AO stacking ontop of these...

With Vertex Lighting i also see a big issue coming our way, one that SL was always somewhat free of... baked coloring (and lighting, which we already have to some degree when uploading meshes, causing the infamous lighting seams if you upload a multi-piece mesh as singular pieces because the normals getting baked as such)

Link to comment
Share on other sites

Posted (edited)
22 hours ago, NiranV Dean said:

All i see is more baked AO.

AO baked into the vertex shading, AO baked into the texture. Realtime AO stacking ontop of these...

I mean what you're talking about is largely what I'd consider an idealists standpoint, in which ambient occlusion is just some thing the viewer does that can be turned on and off.

From an artistic perspective, the ambient occlusion effects the typical viewers people are using provide is minimal and even with ambient occlusion turned on in the viewer, there is an artistic need for more shading, that is typically fulfilled by the creator by using very large textures unique to each section of geometry so they can have ambient occlusion effects.

You're never going to get creators to stop putting extra ambient occlusion effects into their models. You're just not. It's an artistic thing and no amount of technical idealism will change that. Creators are always going to want some level of control over their shading. At least if creators can do vertex shading, they will be able to exercise control over shading, without increasing texture memory usage exponentially as they will be able to use smaller repeating textures throughout a model where otherwise they would use many unique textures.

Not to mention I want to be able to make rainbow brick castles :P

 

Edited by Extrude Ragu
  • Like 1
Link to comment
Share on other sites

On 7/2/2021 at 2:11 PM, Extrude Ragu said:

I mean what you're talking about is largely what I'd consider an idealists standpoint, in which ambient occlusion is just some thing the viewer does that can be turned on and off.

From an artistic perspective, the ambient occlusion effects the typical viewers people are using provide is minimal and even with ambient occlusion turned on in the viewer, there is an artistic need for more shading, that is typically fulfilled by the creator by using very large textures unique to each section of geometry so they can have ambient occlusion effects.

You're never going to get creators to stop putting extra ambient occlusion effects into their models. You're just not. It's an artistic thing and no amount of technical idealism will change that. Creators are always going to want some level of control over their shading. At least if creators can do vertex shading, they will be able to exercise control over shading, without increasing texture memory usage exponentially as they will be able to use smaller repeating textures throughout a model where otherwise they would use many unique textures.

Not to mention I want to be able to make rainbow brick castles :P

 

The artistic need for shading solely comes from the lack of good shading in the Viewer. Shading in general, especially AO is typically done via AO map that specifically tells the renderer what is subject to how much AO, this is especially useful for small details. SL lacks all these things due to LL insisting on keeping SL as dumbed down as possible which in turn creates the need for these hacks.

Just switching SSAO to HBAO or HBAO+ (or even VXAO) would be a noticeable improvement, heck even tweaking the SSAO settings to begin with would be something, right now SSAO can be on or off and there is literally no difference, you might as well keep it off (which you can't because its linked to light softening which also controls shadow smoothness, just another thing that they should fix already)

Link to comment
Share on other sites

3 minutes ago, NiranV Dean said:

The artistic need for shading solely comes from the lack of good shading in the Viewer.


Don't forget you write a viewer for a past time. To a hammer, everything looks like a nail.

I am pretty confident the majority of ordinary users would not want stronger Ambient Occlusion from their viewers. It would break their existing content. That matters a lot to residents when they put investment into it.

As a creator I would not want to face a situation where I find 8 years worth of textures invalid. I would guess most creators feel the same.

What you propose I think you would find is unlikely to be implemented because it would be immensely unpopular to Residents for the reasons above.

Also, don't forget that not all ambient occlusion in a texture comes from actual 3D details  in-world, often creators use trim sheets with ambient occlusion from fake 3d effects in normal maps etc.

 

 

  • Like 1
Link to comment
Share on other sites

12 hours ago, Extrude Ragu said:

As a creator I would not want to face a situation where I find 8 years worth of textures invalid. I would guess most creators feel the same.

Irrelevant, they do it all the time, breaking our content and that is to be expected in a virtual world. We're not talking about a closed system like a game for instance. SL is open and dynamic. Where were you when they broke years of my content with the decision to bring the legacy shiny to Deferred Rendering. What about EEP, it has broken specularity a couple times, not to mention it has broken lighting and a lot of your windlight presets that have been created the past 10 years.

Leaving something the way it was is exactly the kind of thinking that has caused SL to stagnate so much, they fear backlash from breaking things, so they rather leave everything as it is, even if that means leaving in a 20 year old bug (such as some of your attachment slot X Y Z not being mirrored on both sides) but at the same time they get confirmation that they should not do anything that risks breaking content because every time they do break something they get backlash. Their problem is not that they get backlash, it is the fact that it is highly deserved looking at their history track of half-assing everything they do but they take it as confirmation for their expectations of a user who doesn't want change. LL has to learn to differentiate between deserved backlash and undeserved backlash, they have to learn that to move forward you cannot go backwards and more importantly they have to learn to work more with us, integrate us more into their workflow, keep a close watch on suggestions. I have 10 years of experimenting with different things, i can immediately tell them if what they are trying to do will earn them backlash.

Take EEP for instance, did they listen when i told them that making presets a permission-based marketable item? No. The idea of making them items has been there before and was already part of TPV's long go, back then they were not subject to permissions however. Nowadays a text file that contains a set of values is considered intellectual property, rather than the contained marketable items only (textures for moon/sun/clouds) like it was before. I can't go to a SIM anymore, play a little bit with the windlight and then save it for later anymore (say when i come back or want to share it for others to make similar pictures), in case of the Official Viewer you can't even change all of the parameters, the personal lighting window is still missing a good chunk of settings. Instead now i have to write the values down and painstakingly paste the values into a new preset, how was that necessary and how did this help preventing "stealing" presets? This makes taking pictures (something i have loved doing for over 10 years) unbearable to the point that i stopped doing the very thing i loved. Did EEP help me as photographer? No. It broke everything and made everything unnecessarily hard and annoying to use. Did they care? No. Why should they, altering a couple settings? Oh right, Oz told me once why... "no one has yet complained", when i asked him why the Depth of Field defaults are still ass, i'd call that straight up a lie, i'm sure many people have complained.

LL is just lazy and extremely inconsistent.

  • Like 1
Link to comment
Share on other sites

 

7 hours ago, NiranV Dean said:

LL is just lazy and extremely inconsistent.

That's not true. They work very hard and very consistently.

LL are suffering the malaise that stems from a decade of trying to get artful programming out of modern software development management practices, which are only capable of producing programmer art.

#BringBackTheLoveMachine

Link to comment
Share on other sites

Posted (edited)
9 hours ago, Coffee Pancake said:

 

That's not true. They work very hard and very consistently.

LL are suffering the malaise that stems from a decade of trying to get artful programming out of modern software development management practices, which are only capable of producing programmer art.

#BringBackTheLoveMachine

Okay, let me rephrase that and further refine what i said.

Whoever in in charge and has the final say that leads to all of these projects being half assed does not care enough to ask those that have more experience on the matter for help/feedback/suggestion and even if, does not follow through with them due to either budget limits and/or unwillingness to delay a project for the sake of doing it right.

Maybe they should... gather some feedback you know?

Edited by NiranV Dean
Link to comment
Share on other sites

2 hours ago, NiranV Dean said:

Whoever in in charge and has the final say that leads to all of these projects being half assed does not care enough to ask those that have more experience on the matter for help/feedback/suggestion and even if, does not follow through with them due to either budget limits and/or unwillingness to delay a project for the sake of doing it right.

Maybe they should... gather some feedback you know?

It's not that.

Agile, jira, scrum and poker are all fine tools to help non programmer middle management direct a herd of kitten like programmers. 

But they lock developers into forced arbitrary guesstimated time commitments and deadlines, scrum just piles on the red tape, and poker lets management bully the time requirements down. The whole mess gets wrapped up in hours of procedural meetings, ignores technical debt and enforces a QA process that stalls development.

Its great for fixing this very specific bug or that very specific bug in this long list of very specific bugs.

It's great if you're a manager wanting to show that thing X can be delivered in Y time by Z developers before anyone has even written a single line of code (which is why big features routinely overrun).

It's great if your developers are  unfamiliar with the product, subcontracted, and far far away.`

It's horrendous for developers who are unable to work on the project in a wholistic way and give attention where the need arises (and with SL that need crops up a whole lot), it's breaks the final iterative polishing steps as those aren't listed in the very specific work requirements, and the QA cycle means that should problems come up, the developer has likely been assigned other things to work on and wont be able to pick right up where they left off.

SL badly needs small groups of high skill developers with the time and space to go dark, take the project apart, get involved with the platform in a personal way, and make some actual magic. 

Link to comment
Share on other sites

9 hours ago, Coffee Pancake said:

SL badly needs small groups of high skill developers with the time and space to go dark, take the project apart, get involved with the platform in a personal way, and make some actual magic. 

Yes, that small group should be US, the TPV developers who A: have to deal with it when it releases and B: work both as long time users and as developers.

Link to comment
Share on other sites

8 minutes ago, NiranV Dean said:

Yes, that small group should be US, the TPV developers who A: have to deal with it when it releases and B: work both as long time users and as developers.

Right ... that makes no sense in any real world. We're all still waiting on you to submit the poser, remember ?

Link to comment
Share on other sites

Just now, Coffee Pancake said:

Right ... that makes no sense in any real world. We're all still waiting on you to submit the poser, remember ?

And i'm still waiting for that second meeting that was supposed to happen to further discuss the details of the Poser implementation WITH the requested synchronization this time.

Link to comment
Share on other sites

You are about to reply to a thread that has been inactive for 76 days.

Please take a moment to consider if this thread is worth bumping.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share

×
×
  • Create New...