Should we use GLM for Spring and expose it to Lua (unsynced)? I think something like this would be necessary if we want to modernize the engine.
It would help us implement a lot of functionality that has been deprecated in OpenGL.
I have found a number of existing Lua bindings [1][2][3], but maybe we should write our own if there isn't a good implementation.
GLM for Spring
Moderator: Moderators
Re: GLM for Spring
Spring currently uses its own math/matrix code, I wouldn't want both at the same time.
It's possible that glm can be incorporated instead of the current engine one and made synced.
I'm unsure about the gains.
It's possible that glm can be incorporated instead of the current engine one and made synced.
I'm unsure about the gains.
Re: GLM for Spring
Regarding Lua exclusively:
Spring currently doesn't expose any matrix/vector functionality to Lua, and this makes a lot of things harder to write or slower.
I think GLM is a good choice to use for rendering code, as it provides a lot of functions useful for that. The types and operations it defines is suited for that (usually from 1D to 4D).
For synced I would prefer something that's more general purpose, as it could be used for various things, like economy, synced map modification and similar game-specific simulation.
So I'm not sure it would be a good idea to use the same matrix library for both synced and rendering (GLM), as they may be doing two completely different things. Especially if there's a performance cost involved. Unless you could have a general-purpose library that's usable in rendering and comes with no perf cost.
Spring currently doesn't expose any matrix/vector functionality to Lua, and this makes a lot of things harder to write or slower.
I think GLM is a good choice to use for rendering code, as it provides a lot of functions useful for that. The types and operations it defines is suited for that (usually from 1D to 4D).
For synced I would prefer something that's more general purpose, as it could be used for various things, like economy, synced map modification and similar game-specific simulation.
So I'm not sure it would be a good idea to use the same matrix library for both synced and rendering (GLM), as they may be doing two completely different things. Especially if there's a performance cost involved. Unless you could have a general-purpose library that's usable in rendering and comes with no perf cost.
Re: GLM for Spring
There is not going to be support for general-purpose matrix/vector ops on the level of a BLAS lib in Spring if that's what you have in mind.
Making glm sync-safe probably isn't difficult (assuming it can be configured to use no tricks beyond SSE2 under the hood), but even if restricted to rendering the integration could be quite a bit more work than just typedef glm::vec3 float3 depending on differences in operator overloads, etc, which is the real pain.
Making glm sync-safe probably isn't difficult (assuming it can be configured to use no tricks beyond SSE2 under the hood), but even if restricted to rendering the integration could be quite a bit more work than just typedef glm::vec3 float3 depending on differences in operator overloads, etc, which is the real pain.
Re: GLM for Spring
I see, thanks.
Can you elaborate the reason for this?
Can you elaborate the reason for this?
There is not going to be support for general-purpose matrix/vector ops on the level of a BLAS lib in Spring if that's what you have in mind.
Re: GLM for Spring
IMO it falls under scope creep, Spring is not MATLAB.
If there is a strong realistic common need for features requiring GPLA (equation solvers or w/e) expressed by game devs then that can change, but chasing hypotheticals isn't a good reason to add dependencies.
If there is a strong realistic common need for features requiring GPLA (equation solvers or w/e) expressed by game devs then that can change, but chasing hypotheticals isn't a good reason to add dependencies.
Re: GLM for Spring
Personally I'm more interested in just utilizing the vectorized form of calculation (basic stuff like +, *, /, -, =, dot, cross, log, exp, etc. with broadcasting).
Outside of Spring I use Python's numpy a lot, and it's just silly how much faster it is to native Python (getting 10~100 times speedup is not uncommon). I don't think I need to convince anyone on the power of SIMD operations.
Outside of Spring I use Python's numpy a lot, and it's just silly how much faster it is to native Python (getting 10~100 times speedup is not uncommon). I don't think I need to convince anyone on the power of SIMD operations.
-
- Posts: 823
- Joined: 21 Oct 2008, 02:54
Re: GLM for Spring
Then you want to look into SMID building blocks libraries such as BOOST.SMID for example.gajop wrote:Personally I'm more interested in just utilizing the vectorized form of calculation (basic stuff like +, *, /, -, =, dot, cross, log, exp, etc. with broadcasting).
Outside of Spring I use Python's numpy a lot, and it's just silly how much faster it is to native Python (getting 10~100 times speedup is not uncommon). I don't think I need to convince anyone on the power of SIMD operations.