Screenshot feature, rendering different from the realtime viewport

[hazmhox]

As reported on discord, here is the bug... I guess it's easier to track here

Realtime appearance of a scene with some CUA particles

"Offline" appearance of the same scene with the screenshot (camera) button in the toolbar

I was using McGruber Hires, as a precaution I disabled it... same result.
The shot is made with the exact same FOV on the camera and on the screenshot preview.

These are particles I'm gonna release tonight I hope... but this is pretty strange that the "offline" screenshot feature does not render the same thing as the realtime viewport.

The manual shot is made with Greenshot or alt+printscreen.

 

[MacGruber]

Possibly particles are aligned to the wrong camera. If that is the case, its a problem that needs fixing for the particles, not VaM. Note that you can use SuperShot (the new SuperRes plugin) to make a screenshot from the player perspective. That might workaround this.

 

[hazmhox]

Well I would agree if the shot was made from a different angle than the player view, which is not the case.
And the particles are "view aligned" which would mean that in this case, the particles would be aligned the same way.

Also, if you compare the screenshots, you can clearly see that some particles are waybigger than in the realtime view. And the front ones are way more bright and colored. If it was only an alignement issues, the way I did the particle system, we would see at least some of the particles at the same size and color / contrast... but on the shot of the camera button, you can clearly see on the left that some particles don't even have the same saturation.

I'm gonna try SuperShot to see if it change the behavior

Nonetheless, if you think about the feature... it should not be an issue to tweak on the asset end. If you add a button to screenshot "what you see", you should produce a picture that reproduce what you see.

Also, what you suggest is ( I suppose ) more or less impossible. You cannot have multiple orientations for the particles. View, world, facing... whatever you choose, there's only one state possible, and I'm pretty sure that it is based on the active camera or the eye position for the View / Facing alignement. Which means that it still will be wrong from another camera on another angle

 

[hazmhox]

I've tried SuperShot ! This is great ! I did not checked your updates in a long while... i should have haha.

Same result tho... here is a comparison split in 4 ( manual shot + Supershot from the viewpoint ) :

You can see that the contrast is way different, and the size also.

It seems for a strange reason that the light is not processed the same way. On the top right you can see that the particles are heavily impacted by the blue light, so you can imagine how much it is on the bottom. And on the right, you can see that the bottom is also really impacted by the yellow light and the top not so much.

One thing that draw my attention on the light is the fact that, if you look closely on the top left, you'll see that there are absolutely no semi transparent white particles. On the bottom left, you can see that there are a ton of white particles.

I don't know how the engine works on that part... so these are just assumptions.

Also also, another info : these are two-sided particles, so even with mis-alignement, they should be rendering exactly as on the main viewport.

 

[hazmhox]

Another one for the road on the next particle system I'm gonna release.

This definitely a rendering issue, color, light I don't know what the source is, but there is something behind that behavior

 

[MacGruber]

That particles are smaller is expected when using SuperShot. Everything that has it's size determined in pixels is smaller...simply because you render with increased resolution and then downsize the image. If something is 16px in size, after a 4x downscale its only 4px. However, it should not change contrast or colors. You can try taking shots at 1x resolution scale or with VaM's build-in tool, does the same happen then?

Note that while the most recent version of SuperShot is compatible with PostMagic, it is unlikely to ever work with Reshade.

 

[hazmhox]

I'm not working with Reshade, because I love VAM rendering and I try to get the best render possible without using external tools. First, because I like it. Second because it is (imho) way better to release content that will appear "as is" if anyone try it out without additional tools. So no worry about that

About the 1x / VaM's built-in tool, it is already show in the first shot. The large one in the first post of the thread.
This was the first test I did... not using your tool an relying on native features to avoid potential issues that may have been caused by plugins. But the result is the same. Built-in camera or your plugins are rendering the exact same way.

When you look at the shards shot (the last one), one thing i would assume ( I'm not really sure ) is that, it seems that the particles are not affected by the settings of my particle plugin. But a bit influenced by the light. Again, this is just assumption, because this is a realtime modification of the particle system. I don't see why another camera wouldn't "see" the changes made to the particle system.

 

[MacGruber]

Can you clarify what "realtime modification" means here? ANY other post-effects (or legacy image-effects) besides PostMagic won't be supported. Its simply because rendering with a different camera means any effects need to be applied there as well. If you plugin does something weird that is only applied to the main camera, then that won't work for screenshots.

Potential work around could be to super-sampling on a graphics driver level and take screenshots by actually making a screenshot of the window or the entire screen. However, that will be low performance if the super-sampling has to be on the entire time. UI will be smaller, but that's what the UI scale slider in VaM is for.

 

[hazmhox]

By "realtime modification" of the particle system, I mean the settings of the particle system are modified on the fly by the script. There is no post effects, shaders or stuffs like that involved on the camera. I'm doing the exact same thing as what you would do in Unity on the UI when editing a PS but with code
This is exactly why I don't understand... even from another camera, these settings are applied to the system in the scene.

Don't get me wrong tho, I'm really glad you take the time to look at that, but I'm pretty sure that there is absolutely no problem on SuperShot... I'm pretty sure that is is a problem that comes from the legacy screenshot system... which SuperShot relies on maybe ?

 

[MacGruber]

Don't get me wrong tho, I'm really glad you take the time to look at that, but I'm pretty sure that there is absolutely no problem on SuperShot... I'm pretty sure that is is a problem that comes from the legacy screenshot system... which SuperShot relies on maybe ?

The old SuperRes plugin did use VaM's internal tool, but SuperShot is a complete replacement of the render pipeline. Which is why I'm saying that anything ELSE messing with the pipeline to achieve whatever effects won't work (PostMagic works, because that's my own plugin and they can talk to each other)

However, if you really have no post-effects to blame, I'm out of ideas.

 

[hazmhox]

The old SuperRes plugin did use VaM's internal tool, but SuperShot is a complete replacement of the render pipeline. Which is why I'm saying that anything ELSE messing with the pipeline to achieve whatever effects won't work (PostMagic works, because that's my own plugin and they can talk to each other)

However, if you really have no post-effects to blame, I'm out of ideas.

Ho that's really cool ! So, you could also kinda find the origin of the issue

Ok let's summarize... there are two possibilities, Particles are either :
- not influence the same way by the light sources on the screenshot camera than on the viewport camera
- not taking in account the settings of my script on an alternative camera ( which to be honest, seems kinda impossible to me )

Is it possible that @meshedvr uses specific shaders / scripts on the main camera that are not replicated / applied to the screenshot camera while creating the screenshot ? For instance, something that plays with contrasts, number of pixel lights allowed etc... ?

In my case, I always enforce pixel light manually, maybe I should try with the settings at max to see if it changes anything ?

I've tried to search on the web, but I don't see any stackoverflow or gamedev board with similar subject that had issues with screenshoting a scene from another camera :/

 

[meshedvr]

The only difference internally between the monitor rig camera (what you see on screen in Monitor mode) and the Screenshot camera is the screenshot camera renders to a texture (1920x1080). The texture is set to use 8X MSAA so that could also be a difference depending on how you have AA set in preferences. The screenshot AA does not adjust to what you have set in preferences.

I have personally noticed screenshots taken using the screenshot tool look different than if doing a screengrab screenshot using something like the windows Snip & Sketch. I'm not 100% sure of the reason, but I would guess something to do with gamma correction being slightly different between the 2 paths. Unity uses a standard sRGB capture for the screenshot texture.

 

[hazmhox]

Umh ok. It does not explain why the particles seems to be white instead of the color allocated from the particle system tho.

I just noticed something by trying a few stuffs... here is a shot below that renders pretty strangely on the reflection of the slate.
Here is the reason behind it :
- This is a normal particle system with mesh renderer (GPU instanciated)
- The trails are made by the trail material, and the base material of the particle itself is empty. On top (the real scene), it renders properly... the particle not being displayed or even spawned if you look at the wireframe in Unity.
- In the reflection, the purple square are the particles with no material allocated
- In the reflection, it is not clearly visible on the shot, but the trails are rendered properly

Why does this happen ? Based on the wireframe checks i've made in Unity, there are no meshes spawned because the material is unallocated. Why on earth would the reflection show the missing material color ? The geometry does not exists :|

Unless, the render to texture cannot handle the exact same rendering has the main camera... which would explain a lot of things : if the it cannot handle some shaders, it will fallback to an approximation or this error color. My particles being GPU particles, there's a chance that the color, lighting and shadows can be interpreted differently. I don't know if there is any documentation about that ?

 

[meshedvr]

I'm really not quite sure what would cause this. Do you have a sample unity assetbundle that works in VaM like above that you can send me? If so, I could try to debug within the editor to see what is going on. That pink rendering usually means a missing shader.

Mirror reflection also uses render textures, and it is possible it would use a different shader variant for some reason, but I'm not sure why.

 

[hazmhox]

I always forget to export the asset, I'm gonna try to do that tonight >_<

I've thought about something yesterday tho, I've tried to align a preview, like this :

And here is the original shot :

In this case here is the setup :
- 4 pixel lights, 3 are blue, 1 is white in the background for the rim light
- The biggest CUA ( that produces the largest white smoke ) has some parameters modified to have a blue tint.
- The smallest CUA ( that is at the center of the hand ) is not modified at all, and its color is influenced by the lights

In the "preview alignement" you can clearly see that the light as almost no effect on the biggest one and that for a strange reason, the color tint isn't visible... so my question is : are additional cameras culling lights ? maybe sRGB is a problem ? or maybe... the materials used for the particles are not translating well with the render path of an additional camera ?

I've seen a few things about linear and gamme color space like this. Or alpha transparency issues like this.