From Neos Wiki
Jump to navigation Jump to search

Geenz's Bi-Weekly office hours for graphics.

Here are the notes from 16th September 2021.

These are rough notes typed by ProbablePrime. If there are errors please edit away! I lost a few places here and notes suffered. Do edit if you would like to help!


Please do remember to check our Roadmaps as a lot of questions here are partially covered there. Do continue to ask them but the roadmaps are there for you to read:

Information on Color Management

We have some Good news, we're changing our approach a little bit.

We're taking a different approach here than usual. We're phasing stuff up a little bit:

  • Certain graphical changes such as changes to AO(Not the ability to adjust it, just tweaks), are going to be released at some point duriing the next build or two.
  • Additionally, tweaks to motion blur will be changing in a similar manner as a smaller item although not in the next build or two.
  • Support for forward rendered lights and objects. Toon Shader/Semi-Transparent Shaders will have up to 16 lights affecting them.

These will all be shipping in the relatively near future! as smaller parts of CM.

We're doing this because: adding CM to everything is arduous. Lots of situations to handle. A/B testing etc to see what we need to do.

We're also going to be bringing over some of the tooling before the release so stuff can be worked on and tweaked a little bit side by side.

For example, You'll be able to look Darker Ambient lighting, side by side between builds without worrying about breaking stuff

Additionally, we'll bring other tooling such as amient light adjustments sooner rather than later. To make stuff easier to work on and tweak.

Just to be cery clear, No release date!


Alex rainbowdashie:Q is colour management coming soon?

  • No release date, see above notes.

Spex: Q: Was speaking with Gareth48 and he noticed that Metallic Smoothness maps can be combined with AO Maps with clever use of color channels. With Red being Metalness, Alpha being Smoothness, and Green being AO-ness(??).However the Blue channel is not utilized. It'd be nice if Height could be in the blue channel to create a nice, compact, Metal + Smooth + Height + AO map. Any chance we could see this happen?

  • So that's a weird one.
  • Metallic maps are showing sort of reflection occlusion and not ambient occlusion. Due to PBS for the most part. you can mask reflections using Metallic. With standard AO/PBR, reflections layer over the top.
  • Geenz will have to go back through the shaders to see if Blue is actively used in any maps to see what they can do. Geenz doesn't want to confuse anyone by doing something non standard.

'Turk' Q: I had a user talk to me about Toon ShadowRamps and that may not be behaving correctly in Neos. From what they explained it's supposed be affecting the final shadow, but instead it does the ramp, then Neos's real-time shadows affect it. Is this the case? Or is there more going on there.

  • This is a Xiexe question/issue. Geenz wants to tear that shader apart and take a look at it.
  • In theory it should impact the final shadow. From what they've seen it does appear to be doing that. In some cases it seems a bit exaggerated.
  • Depending on what shadow settings are used, soft/hard it can affect the shadow ramp.
  • Geenz wants to take a further look at the shader later to maybe replace or adjust it.
  • We may be able to bring stuff over from poiyomi but we still can't bring over poiyomi.

Prime: Why do people want poiyomi?

  • People say its better?
  • Please request specific features from it.
  • Kulza: Masking and emission settings
  • Enverex: a billion options and models are made to support it.
  • More on poiyomi from Geenz:
    • A ton of features, doesn't mean a good shader
    • What are the big ticket items that you need.
    • One thing that needs to be taken into account is the transition to the new engine.
    • What gets involved when moving to the new engine is trying to port over ALL the shaders so they work.
    • Porting over poiyomi is a huge task and would take a lot of time due to its settings and options.
    • The way Neos's shaders work, it would take forever to compile Poiyomi for Neos. So we can't support it right now

IF YOU HAVE SPECIFIC FEATURES we can implement them on their own.

Flute: Hi Geenz~ Q: Any plans to improve the quality of camera/screenshots? They are rather compressed. Especially around gradients and dark environments.

  • If you go through and inspect a photo in world from the camera you can disable compression which should give you a lossless image. Flute meant saved screenshots though ones that are saved to your computer.
  • Geenz is not seeing compression artefacts. So they are nto sure what the problem is or where Flute migth see it. They checked some of their screenshots and they don't see any compression artifacts.
  • Please show Geenz some examples and they can take alook.

Alex rainbowdashie Q: Will the SSAO be togglable/intensity able to be adjusted by the end user?

  • That will most likely be a world setting rather than a user setting.
  • As far as moving it as a user, that's more unlikely. We should preserve the look and feel of users worlds. We'll see. It depends on the settings and UI changes that we'll need to make here. For now the answer is no, later it'll be a world option.

Enverex: Q: With forward rendered objects now (when that change goes through) handling more lights, is that going to have a substantial effect on performance?

  • That depends on how many forward rendered objects you have. Too much transparency/Too much toon lit it will be slow.
  • Second of all, lots of lights concentrated on one location will also be show.
  • Most hardware should be able to handle it and forward rendered lights at substantial amounts.
  • This come back to, being careful about how you design and build worlds. be mindful that this area is kinda exponential. More Forward rendered lights or objects means more performance cost.
  • This is also why we're trying to move to "Forward+" rendering.
  • This change should make stuff involving FW rendered objects or transparent objects look a little nicer which is the goal.

Gareth48 I made a plugin that updates all textures under a root from Bilinear filtering 8 samples to Anisitropic filtering 16 samples. When I run it on Soujurner's island it converts all the textures instantly and then afterwards there is no noticeable change in the performance. What exactly is the cost of using more refined filtering modes, if any? (Yes i will release the plugin decently soon)

  • This kinda carries over from trying to get Neos to run on mobile platforms.
  • Anything above bilinear can be slow on mobile devices.
  • These are low energy devices so this has impact on them.
  • If Quest isn't your goal, you can ignore bilinear.
  • We do have some stuff that needs to support quest in our platform and we want to return to that. So we're keeping it to bilinear.
  • We could probably bump it up to trilinear.
  • Between 8=>16 samples it's a small difference for linear
  • With anisotropic filtering, the samples lead to a lot of performance loss.
  • With most desktop hardware there shouldn't be much difference in performance between linear and anisotropic. So it depends if you want to support quest.

Turk Thank you for the answer :pray: then followup Q. Q: If you do tear apart of the XieXies would you be willing to do an open feature request or board so people can add all the features people would want with it? Initially when we added it, we went with a very average good enough approach People have wanted some masking, matcaps, etc. But some of them have felt weird, or implemented differently as well to what people were expecting visually. Just to have feature parity with other platforms.

  • Geenz would be open to it, when it comes down to modifying 3rd party shaders we want to keep it to a minimum. Lets stick to the most important big ticket features and options.
  • If its really big stuff that would have value, which doesn't result in 20 other options it can be considered without clogging up other priorities.

Alex rainbowdashie: What Is the camera issue and mirror issue where it goes all black in some worlds With artifacting weird drawing on it or becomes completely black when the skybox is visible

  • This thing is probably some stencilling issues, for mirrors geenz wants to take a look at them in the future to see if they can make them a little less janky. So we'll see about that.

Gareth48': Is it more efficient to have a sprite sheet containing 30 or so icons on one material and then individual quad meshes with uv offsets displaying each icon or is it more efficient to have 30 materials one for each icon and an instanced mesh. In a more broad sense what is the cost for creating too many materials ?

  • The first one.
  • The reason with that is how material patching works. you touched on technical stuff.
  • Instancing vs, material batching.
  • You can have instancing and material batching work together. If you have 30 quads with the same material you could.
  • Once you combine stuff like material property blocks, you could put an offset for each block it would allow better instancing and batching.
  • Geenz wants to write up a guide on this.
  • TL:DR: Abuse material batching right now. It'll only be a problem for really high poly meshes.

Prime would like that guide he got lost in this answer. Sorry D:

Enverex: Q: Following on from my earlier question: Neos only supports real-time lights, so all my worlds use large amounts of them, because there's no other choice. I'm not using toon shaders in my worlds, but lots of users use them for their avatars which I obviously can't influence, hence the question about performance concerns (less a question, more an elaboration)

  • Relatime lights and rendering.
  • Every object in neos has a bounding box(EVERYTHING). There's some sort of metric to define where something is in the world and how big it is to. We use this to determine how it should be used in the world and rendered.
  • In forward rendering we create a list of lights that affect objects based on this. So we have a list of lights and a list of objects. We can then intersect these to figure out the rendering needs. That's what leads to the performance costs.
  • Due to CM, you'll right now have to make lights bigger than you need. But after CM you might be able to shrink them to be more performant as lighting changes.
  • With all of this you can figure out, think about the performance of these lights on your toon lit materials.

Prime also got lost in this one, he is sorry :(.

Engi: Q: With the current implementation getting limited use due to its odd interaction with the render queue (especially with rendering over UIX), what are volumetric going to be like in the new engine? In other words, how different will they be from the current implementation and what might be done to avoid the current problems?

  • This migth be affected by the new render queues in the new engine which will lead to more flexibility here.
  • Its going to be a developing issue.
  • Geenz will post more when they have more.

Gareth48: THANKS! Why is it that when using exclusively the albedo channel that totally nonreflective PBS_Specular is noticeably more saturated than PBS_Metallic

Prime is sorry, he lost this one too.

ElektroSpy Questions

GPU particles

- In one of the other office hours, we briefly touched upon the topic particles, small follow up question to that: -- would this allow us to emit particles from a mesh (surface) / masking texture and/or could this already be implemented with cpu particles ?

  • You can emit particles from a mesh's vertices. You're not asking for that. You're asking for triangle emission?
  • GPU particles can be very powerful, its easy to make them super slow. You could emit from the surface of a model with GPU particles but that would be slow. Masking textures would also be slow.
  • We'll look into it at some point but don't get your hopes up as far as GPU particles go. In the initial iteration its likely to be computed from a texture etc that's rendering particles on the GPU

Material PropertyBlocks

- do these blocks cause additional draw calls ? - if no: can we consider them to be more efficient then separate materials ?

  • Yes they are more efficient than separate materials, you can optimize stuff and tweak the innstancer with this. They can be more eficientt. depends on usecases though.
  • If you have 5-10, with 5-10 different materials. material property blocks not help.
  • 100s or 1000s of materials, consider using the blocks.
  • At some point, we'll be adding more material property block options for more use cases.

USD file support (Universal Scene Description)

- - really far ahead in the future question: -- did the team talk about supporting the in/export of this format ?

  • Kinda. USD is great for a lot of reasons. We haven't really talked or look at it. Its more a conversation/interop with other things etc. Such as export/import.
  • Geenz does not forsee support in the near time. Would have to wait for new engine.

Geenz can't really talk about the other 2 here.

World loading times - Some users (including myself), often experience long loading times even if everything is already locally cached -- what eats up most of the time ? -- is it the amount of objects/components/slots? -- does this have anything to do with the de-serialisation of the object list from the session? - Are there any methods to do optimise this from the side of the creator ?

Syncing process - what does the system do, prior to starting the upload after saving ? -- Long wait times prior to actually starting the upload