Closed fire closed 4 years ago
You can increase resolution of baked image in TestScene/ViewportBaking/Camera by modyfiing parameter "Image Square Size" to something like 16k. But importing big textures in Godot is very slow right now. Right now one frame of 4k image with 16 frames is roughly equal to 256x256pixels. This is not enough for close viewing of impostor.
So using 16k textures will give me 1024X1024 pixels?
Yes, You can also decrease a "Grid Size" parameter but it could not be enough for proper illusion. The formula is image_square_size/grid_size.
I also looked into rotating the object to fit the square area, but I didn't have bandwidth for it.
An inspection of the png shows that 1) it is missing dilation 2) The content area is very small.
Is it possible to use more sets of textures?
I think it is, but I am not sure if it's really a good idea. Those textures are few megs each so it won't be a great optimization. I tried to bake this model and i found out that import texture settings were kind strange. Here is the result with my settings: https://streamable.com/t07jlk I think its not bad for 256x256 frame size. Also please check if all textures are correct in impostor shader, it seems like normal map was a wrong file.
And here is 8k texture version with 512x512 frame size: https://streamable.com/8pyy7v Looks really nice but texture weights 14 mb. I think at this point its probably better to use some LOD version of real model.
Someone told me we should using texture arrays. https://docs.godotengine.org/en/stable/classes/class_texturearray.html to allow mipmaps.
I've also have tools for LOD (mesh decimation) and scene merging.
I didn't know that we could use texture arrays in shaders. I will look into this tomorrow. I am not really sure what improvements to expect with this change, probably Shader code will be simpler?
So we have mesh decimation and billboarding. The biggest problem is a lack of some kind of logic to automatically swap meshes by view distance. I think it would be simple with single MeshInstance, but not with MultimeshInstance. It would be nice if Godot have something like that integrated into its source code.
The main thing is mipmaps are allowed.
It seems that sometimes Texture Array is not imported properly after baking. Other than that I think its working properly. On the other hand, I'm worried about two other issues. First of all, the constant GL_MAX_ARRAY_TEXTURE_LAYERS limits us to the maximum of 16x16 frames in opengles 3. The second problem is the lack of any support for Array Textures in opengles 2. I am not sure if we should go this way.
https://opengles.gpuinfo.org/displaycapability.php?name=GL_MAX_ARRAY_TEXTURE_LAYERS&esversion=3 Interesting numbers on the max.
I don't know how long opengles 2 will exist in Godot Engine.
Its in a texture_array branch for now. According to this https://godotengine.org/article/abandoning-gles3-vulkan-and-gles2 GLES 2.0 will stay in Godot 4.0.
You can increase resolution of baked image in TestScene/ViewportBaking/Camera by modyfiing parameter "Image Square Size" to something like 16k. But importing big textures in Godot is very slow right now.
Did you disable Import Etc2 in the Project Settings? ETC2 is notoriously slow to import compared to other texture compression formats.
No, I have not disabled this option. However, I don't see many alternatives. Same as in this article, textures use all 4 channels (RGBA) to save some memory. From what I understand, Import Etc does not support the alpha channel, and the other options are not supported by Android. In addition, it appears that Import Etc2 will not work on GLES 2.0, so the current implementation will not work in this case. I should probably only use RGB channels or distinguish between GLES 2.0 and GLES 3.0 versions.
After a moment of thought, I disabled Import Etc2 for Baker. If someone needs the Android version, they will simply import the generated assets to another project.
The main advantage of using texture array is the ability to avoid texture sizes of atlasing. Even if each image in the array has a max size of 2k, that is a lot more than the limits of 256.
Are you able to update the texture array branch? I'm having a hard time upgrading the code. Wanted to test it.
Yes I'll do it. I'm just waiting for some minor corrections to the pull request because it introduces very big changes that would require re-modifying the TextureArray branch again.
Ok, I added TextureArray on master as another shader option. TextureArrays baker uses ugly workaround for importing as correct resource, so I cannot guarantee that it will work on all operating systems.
I'm unable to open the new baker ui on master https://github.com/wojtekpil/Godot-Octahedral-Impostors/commit/7e96db2ec35a9b6e8e53fe73a0ada5ded511a025
Edited:
It was moved :o.
Yes please, read README file. It now works as a plugin. Just select any MeshInstance and click this button:
I can't test it, but I'll open a new bug for the other issue.
I tried the test and it still seems like the imposter size is very pixelated. Is it possible to use multiple texture atlases? I assume the limit is one texture for each frame of 16x16, this can then be combined into the texture array.
However you don't need to do one texture for each frame, you can do like 4 or 8 or any multiple of 2.
For now I don't have plans for textures atlases. It's too expensive in VRAM memory. Right now 4k version costs about 60 mb of VRAM. It's a lot and for an LOD system it's probably too much already. We can go as low as 7.5 mb with some optimization like 2k textures color/alpha and 1k textures for everything else. But I see that your goal is to achieve better quality. In that case, I'd probably use some mesh optimizer right now.
I've already done the mesh optimizer / merging code. Wanted to develop this part of the code.
Will close issue because many things have changed in repository and I need to re-evaluate the problem.
Was capturing https://github.com/vrm-c/UniVRM/tree/master/Tests/Models/Alicia_vrm-0.51 and I could not get the output to look detailed and smooth.
Rename vrm to glb.