Assets: standard environment

The assets all currently seem to be using very different ideas of environment/world setup. There are two main problems I saw:

1. I was not able to find a case where the model in the .blend renders out to any of the screenshots.
2. It is inconsistent what the top level object is in these assets. Sometimes it is wrapped with a parent object (it should be), and sometimes it is not (like in the case of Jun avatar).

I think the rule should be if we’re doing screenshots to show that an asset is done, then the file should at least have the capability of snapping that screenshot without changing deep blender settings.

Since I am doing composing and engine work now, it is important that assets can be copied and pasted between scenes and they always look this same. This only works if they are designed to render in a specific lighting scheme, and if they can actually be copied/pasted (which collections cannot).

[avaer]

Models made of different parts should be parented to either their rig (armature object) or an Empty.

I agree.

Rigged objects are consistent across the copy/paste buffer you are using to compile a scene. I’m not 100% on the Empty solution, (I am fairly certain it works, since sketchfab models converted to gltf etc use this method)

Yup it worked for me.

I made a photo studio blend which could serve as this. It’s marked out with comments on how to use it

Yeah, sorry, I should have used it. Can you link here posterity? That’s the better call, though the problems I experienced were more on the source side than the destination.

This might be a ridiculous request, it might not - but if we have an equirectangular image capture of a preferred in-engine (Webaverse) environment, we can literally test things in Blender with that as our environment texture. It will not be perfect, but if you have a preferred test/lighting environment (that doesn’t contain other light sources), we can do that. From my understanding the current skybox etc is procedural, so I don’t think this is possible.

This should be driven by the artists so if you want to make that call, it would be on the engineers to implement it. We do have things like procedural sky, but I think for now we’d just use whatever HDRI the art team selects rather than trying to do that part dynamically. We can revisit this later.

Hopefully that makes this less ridiculous 😄.

https://github.com/webaverse/app/issues/1393#issuecomment-886689890

Awesome, thx for the test case!

We probably want to block (non-baked) ambient occlusion, bloom, SSR and all other forms of post processing unless we can reliably recreate them in engine, which to the best of my knowledge, we can’t.

Yup, not yet. But these are great ideas.

Emissives won’t be as obvious in that case and should probably be previewed in their own emissive pass render so it’s clear what’s emissive and what isn’t.

Excellent observation. I made an issue for bloom: https://github.com/webaverse/app/issues/1398

[Vianvolaeus]

Apologies, I had a comment for this and thought i’d posted it:

Can you link here posterity? (photo studio)

https://drive.google.com/drive/u/1/folders/1FfsGpsKYlB7zkA43OzrqFmDFoLgo6Jyk

I made a short video on using it as well, but it does have comments / instructions built in:

https://www.youtube.com/watch?v=dAM2RrfYWL8

It might be worth me revisiting this and polishing it up. It was originally made so we actually had an interesting scene to preview items for socials, etc for teaser content, but it can definitely work for other workflows.

Default HDRI is the right call I think, since that can be transferred across pretty much any location for input / output of content. Although we’re likely going to be in a solarpunk setting and likely a green field-ish location, we should probably use a studio lighting environment to avoid color influences. I’ll test some we’re available to redistro if needed (cc0)

Thanks for making the issues. I think Bloom is the more important one FWIW, since we can do some level of baked AO in gltf.