Open oxplay2 opened 5 years ago
Thanks for Reporting, so this is definitely an important feature to have. This issue is two sided so I might open two sub issues for this:
As you say this needs the openGL 3.1(?) core profile, which is set using the AppSettings. This will be the problem we have to think about for various reasons: The Core Profile would affect every shader, allowing the user to use more recent openGL features on Mac OS (which requires the core profile), break many existing user shaders which rely on the compat profile (deprecated stuff, backported stuff). It would also prevent the SDK from launching on GPUs with << openGL 3.1, thus we need to find a way to make it configurable, even before/during the sdk launch, which is uncomfortable.
This is just a swing problem. Someone could think about how we implement Texture Arrays the best: This could be done half-heartly with a ComboBox/DropDown to select the Texture and an Edit Button or something more fancy like a tree view or something. Maybe you guys could do some research on how this is handled in other engines?
And here we are, stuck in the "but muh legacy hardware" mindset that's been plaguing jme for quite a while now. OpenGL 3.1 was released almost 10 years ago. IMHO anyone with hardware older than that is gonna have a hard time anyway. SDK is a tool for devs, not the end users and it can be assumed that devs usually have at least semi decent hardware. It's not like the sdk has to run on Android either, so I really don't see a reason not to bump the required OpenGL version to 3.1 or 3.3.
That's true, but the problem actually goes both ways: What if someone want's to use the openGL 4.4 core profile? What I could think of is doing it like with the dark monkey theme, where there is a properties file generated and the default could be 3.1. For this we have to look/wait/think about @riccardobl s PR which added/renamed a few constants to actually even support the profiles. Was this only relevant for lwjgl2 or also 3?
Afaik Riccardo's PR is only related to lwjgl2. I might be wrong though.
A config file seems like a good idea, but I'm not really sure who is going to use it, considering the amount of sdk development going on. It would make a possible future version bump much easier though.
The PR in question, are actually two this one: https://github.com/jMonkeyEngine/jmonkeyengine/pull/1096 that added support for the lwjgl2 renderer (lwjgl3 should already be fine) and this one: https://github.com/jMonkeyEngine/jmonkeyengine/pull/1099 that renamed the constants (by deprecating, not removing, the old ones) These constants are strings and their value has been left unchanged and the old and new constants point to each other (as you can see from the final code). So, they can be used interchangeably and you have full backward compatibility on this side.
JME Material definition can use(for AppSettings.LWJGL_OPENGL3) for example:
TextureArray exampleTextureArray
that in SDK material editor open only one texture, while should open more.