Supermodel Forum

Thanks for bearing with me on this Ian.

If I file a bug report to mesa I think they will strongly push back with strong reasons.

1- texture2DLod is not allowed on fragment shaders by the specs
2- mesa already provide a workaround through the environment variable to allow "non-compliant" code to run providing a warning

Bottom line they will tell me to go away.

What should I do?

If the code is not going to be fixed because that would represent a lot of work (without having a clue on which or how many changes it would need) I think that at least the use of force_glsl_extensions_warn=true workaround to run Supermodel on Linux should be clearly documented in https://github.com/trzy/Supermodel/blob ... /README.md and also https://github.com/trzy/Supermodel/blob ... README.txt so people is aware of this.

Would be great to also hear Bart's thoughts on this.

I wish I knew GLSL so I can create a PR myself but this is the first time I ever look at shader code.

Just dug through the spec. The reason all the implementations support it is because they support this extension

https://registry.khronos.org/OpenGL/ext ... re_lod.txt

Which explicitly adds support for the lod functions for fragment shaders. Like I said even apple supports this.

Is this missing from the mesa drivers?

You can try adding this to the shader

#extension GL_ARB_shader_texture_lod : require

This makes a lot of sense and goes inline with what I've been reading in different places and the behaviour we observed.
I'm pretty sure that mesa also support the extension and all that is needed is to enable it in the code. The reason for this is because allowing a more relaxed behaviour also solves the issue so it means the functions are there, just not "presented" unless explicitly enabling the extension or telling mesa to enable the extension even if not explicitly requested.

I can try this out and report back, but just to confirm in which position in the shared file should I add that line? Anywhere? Right below the #version 120 line?
If right below the #version 120 line, should I do it twice under each occurrence?

Version declaration is always the first line in a shader. So immediately after should be fine

Confirmed Ian.

Adding #extension GL_ARB_shader_texture_lod : require right below #version 120 in line 64 solves the problem.

Would you modify the code yourself or you prefer me to create a PR in Github?

After testing I can also confirm that it’s enough to set the extension to ‘enable’ instead of ‘require’.

fc7 wrote:Finally solved it!

I missed another occurrence of #version 120 on line 64 of Graphics/New3D/R3DShaderTriangles.h.
Replaced it with #version 130 as well and recompiled.
Now all errors are gone and 3D graphs are rendered correctly!
I only tested Daytona 2 for a few minutes but everything seems to be fine so far.

Not sure if other shader files for the new 3D engine needs to be changed as well. For example effects used by other games that Daytona doesn't utilize.
I guess I will get errors in supermodel output and at least I now know how to approach the troubleshooting.

Any chance you can consider changing this in the code if only when compiling for mesa/Linux?

Thanks.

Great job man. Never know why Mac users could not use new 3d engine. Would it be possible for you to share that modified version you compiled?

fc7 wrote:After testing I can also confirm that it’s enough to set the extension to ‘enable’ instead of ‘require’.

Can you make a PR to submit?

PR created: https://github.com/trzy/Supermodel/pull/25

Glad to contribute in even the smallest way with this great project.

Thanks guys.