wojtekpil / Godot-Octahedral-Impostors

Octahedral Impostors implementation for Godot Game Engine
MIT License
270 stars 30 forks source link

Waiting for Godot Engine 4 #19

Open fire opened 3 years ago

fire commented 3 years ago

HLOD and LOD systems are now in Godot Engine.

Any approaches for 4.0 support.

Can provide coding assistance.

wojtekpil commented 3 years ago

Hi, I have hard time using 4.0 builds right now, so I will probably wait until it's more stable. In the meantime you can check new version of this plugin (https://github.com/wojtekpil/Godot-Octahedral-Impostors/tree/v2.0-new-baker). The baker and the shaders are rewritten, and results are much better comparing to the old release. Few examples: https://streamable.com/zmp4sg https://streamable.com/lusnwr https://streamable.com/ls7o4g New batch baker: https://streamable.com/czjk40

fire commented 3 years ago

What happens when you bake a character?

wojtekpil commented 3 years ago

It probably won't look good, especially arms in T-pose. Octahedral impostors with depth offset are used best with cohesive shapes. I am also not really sure if baking characters is really useful with this method. It's mostly for static meshes (except some shader based animations like wind etc). But it could look better than in old method.

fire commented 3 years ago

The concept is:

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

https://media.discordapp.net/attachments/835369558541467668/854022573474316298/0JHYN0d.png?width=835&height=596

sebastianrueckerai commented 1 year ago

@wojtekpil since it is out of beta, do you have any plans converting imposters to Godot 4? I would love to use it and can offer my help in coding (though I so far have developed only games, not addons).

bongblender commented 1 year ago

I have successfully repaired your 3 shaders for use in Godot 4 and they are now working perfectly. However, I did have to bake them in Godot 3 and then use the resulting textures in Godot 4.

I want to encourage you to consider porting your plug-in to Godot 4 as it is stable enough now. I am not very good at plugins, but I believe that if you try, you could get it done in a day at most. All you have to do is work on your old code.

If you need any help, I am happy to share my progress on the addons I have been working on so far. Also, I have attached the 3 shaders for Godot 4, as well as the normal_baker material for your convenience. shaders.zip

InitialCon commented 1 year ago

I've started porting this to Godot 4 over at https://github.com/InitialCon/Godot-Octahedral-Impostors but I've run into a few roadblocks since I'm quite new to the API changes in Godot 4. So far I've got everything ported except for getting the final baking process to run smoothly. It might be useful to someone just having this available as a base. If anyone is willing to help me with the last 10% of this I'd greatly appreciate it and open a pull request with the result.

fire commented 1 year ago

I can look into it.

InitialCon commented 1 year ago

That would be greatly appreciated. The shaders and most of the code work perfectly but my understanding of windows and the new way directories are handled is holding me back here. I'm going to sleep now but I'll work on this more in the morning.

wojtekpil commented 1 year ago

Sorry for the late reply! Thank you for your work on this port :) I think most irritating issue in Godot 4 will be handling linear color space on viewport. I don't think that keep_3d_linear is implemented, so we would have to convert it in shader to basically invert srgb conversion (sadly loosing a bit of precision). I can try to look at script issues too in my free time, but I am not an expert regarding dictionaries changes either (and it was a real pain to work with it in G3). Overall I need to experiment a bit more with this solution in G4.

fire commented 1 year ago

@wojtekpil this thing? https://github.com/V-Sekai/godot-vrm/blob/master/addons/Godot-MToon-Shader/mtoon.gdshader#L176-L180

InitialCon commented 1 year ago

Didn't even realize that the color space would be an issue. The hardest part for me so far has been understanding how editor plugins and file access are supposed to work.

wojtekpil commented 1 year ago

@fire yes, this thing. This should be enough for normalmap/depth map. But overall it cannot be used for things like color id map (or encoding 16bit data into two 8 bit channels) because it is not precise enough. But for our use case should work. Yes, file access was a pain in G3, hopefully they improved it, especially importing assets from a plugin. This was one big hack.

fire commented 1 year ago
Error EditorFileSystem::_reimport_file(const String &p_file, const HashMap<StringName, Variant> &p_custom_options, const String &p_custom_importer, Variant *p_generator_parameters)

This thing? https://github.com/godotengine/godot/blob/master/editor/editor_file_system.cpp#L1932-L1937

References

fire commented 1 year ago

If you need it we worked out how to extract a 16-bit integer in a FORMAT_RGBAH https://v-sekai.github.io/manuals/decisions/20230415-rgbaf-to-store-integers.html

sebastianrueckerai commented 1 year ago

Hey @wojtekpil ! This may not be the best forum for my question - in the case please tell me if there is a better place for it!

Is it possible to use imposters with multimeshes to show distant grass or foliage?

Specifically, I would love to use it with scatter (https://github.com/HungryProton/scatter). I am unsure because scatter takes a while to load it's elements (initially it can look like an empoty node) and if the imposter is created to soon, it would maybe not show anything?

wojtekpil commented 1 year ago

Hi, honestly I am not sure, definitely it is not a solution for grass. Octahedral impostors needs a quite big texture for baking everything. Shader is quite complex too so it might actually take a bit longer to load. I did some tests of using multimeshes of impostors though. With high poly vegetation assets it should make sense to use it that way (take a look at vertex count in this video https://www.youtube.com/watch?v=FkZR1mD4_cI ). I posted a screenshot of more dense application too here: https://twitter.com/wojtekpil/status/1553836625528033284 But I never actually tried to bake full multimesh as a single object. I suspect that it will not look to good, because of perspective issues, but you can try.

wojtekpil commented 1 year ago

@fire yes reading 16 bit image as int in shader is possible. Saving it is problematic

sebastianrueckerai commented 1 year ago

Thanks for your reply and the links! :)

it will not look to good, because of perspective issue

I am not so sure. The use case I have in mind is very distant grass. Like looking down from a mountain in Skyrim. It has always bugged me that far valleys loose their grass when looked upon from a distance. Having an impostor for a whole area of grass (not individual blades of grass) may be better than having none at all or just having a flat texture.

I will try to see if I can make it work over the weekend an report back how it looks!

Zylann commented 1 year ago

For mid-range maybe less dense, grouped grass can do the trick, but I think for very distant grass it's not even impostors you need, but rather a layer that renders with the terrain's pixel shader itself.

SlashScreen commented 1 year ago

@wojtekpil I'm throwing my hat into the ring fixing up @InitialCon 's 4.x port (because I need impostors badly) and I had a question about a particular line:

func bake_map(map_baker: MapBaker, scene: Node3D, vp: SubViewport, postprocess: Mesh) -> void:
    vp.keep_3d_linear = not map_baker.is_srgb() or map_baker.is_normal_map()

SubViewports no longer have a keep_3d_linear field, as you previously mentioned. There is a PR, but it hasn't yet been merged. However, there are formulas to convert it within the shader code:

vec3 linear_to_srgb(vec3 color) { 
    return max(vec3(1.055) * pow(color, vec3(0.416666667)) - vec3(0.055), vec3(0.0)); 
} 

vec3 srgb_to_linear(vec3 color) { 
    return color * (color * (color * 0.305306011 + 0.682171111) + 0.012522878); 
} 

(Source) What parts of the process assume that the working color space is linear? Perhaps I can insert these functions as a workaround. I can see from the code that it expects linear when baking normals.

SlashScreen commented 1 year ago

I've gotten it to progress without any errors, but the shader seems to be broken, and the bake outputs.... don't seem right. Look at my PR for my progress: https://github.com/InitialCon/Godot-Octahedral-Impostors/pull/1

InitialCon commented 1 year ago

Sorry for disappearing for a while. As I've commented on the pull request I believe the only issue currently is how the files are saved. I'll attempt to rewrite that this Friday but I may need assistance as I'm unfamiliar with file access in GD4. Once the file saving is fixed I'll have a look at finding other bugs or issues from my first port attempt.

zhangjt93 commented 1 year ago

@wojtekpil I'm throwing my hat into the ring fixing up @InitialCon 's 4.x port (because I need impostors badly) and I had a question about a particular line:

func bake_map(map_baker: MapBaker, scene: Node3D, vp: SubViewport, postprocess: Mesh) -> void:
  vp.keep_3d_linear = not map_baker.is_srgb() or map_baker.is_normal_map()

SubViewports no longer have a keep_3d_linear field, as you previously mentioned. There is a PR, but it hasn't yet been merged. However, there are formulas to convert it within the shader code:

vec3 linear_to_srgb(vec3 color) { 
  return max(vec3(1.055) * pow(color, vec3(0.416666667)) - vec3(0.055), vec3(0.0)); 
} 

vec3 srgb_to_linear(vec3 color) { 
  return color * (color * (color * 0.305306011 + 0.682171111) + 0.012522878); 
} 

(Source) What parts of the process assume that the working color space is linear? Perhaps I can insert these functions as a workaround. I can see from the code that it expects linear when baking normals.

I have implemented a version compatible with Godot 4.1.2 and submitted issues. I hope it can be helpful to you.

https://github.com/wojtekpil/Godot-Octahedral-Impostors/issues/20

RichMakeGame commented 10 months ago

I'm having issues with lack of linear viewport colour in 4.2. I'm using the result of a render texture in a shader and the loss of precision using the conversion is causing artefacts