I know it’s been asked many times before, but I was wondering if there are any plans to add support for features such as geometry shading, tessellation and so on?
It’s not like you’d have to destroy backwards compatibility. The way you could do it is by checking if the hardware supports the features before attempting to use them (the good thing about jME3 is that you’re not leaving it down to the developer to set the gl program to use, so you could filter geometry shaders from being used where not supported).
Doing this would really push jME up to speed. As it is, other engines have these features, and as a result can create showcase worthy work thanks to the fact that alot of modern-old hardware (GTX ~400 is pretty old) supports this.
I just think that, as an alive project, you should focus on maintaining backwards compatibility, as opposed to fully supporting old hardware (which is what it seems is being done)
I think the reason you don’t see these features yet is because no one has submitted the patches.
As an aside, GTX 4~ may be pretty old but easily less than half of Mythruna’s users have a card even that powerful. Most are much much worse. I don’t know what the numbers are these days but GTX4+ is probably 30% or so of the available gaming market. Which may be ok if you really need those features… but beware jumping in just because it sounds cool.
@pspeed said:
I think the reason you don't see these features yet is because no one has submitted the patches.
As an aside, GTX 4~ may be pretty old but easily less than half of Mythruna’s users have a card even that powerful. Most are much much worse. I don’t know what the numbers are these days but GTX4+ is probably 30% or so of the available gaming market. Which may be ok if you really need those features… but beware jumping in just because it sounds cool.
I’m pretty sure I saw a patch submission adding basic support for geometry shading and tessellation from early 2012.
I can imagine that they don’t have cards that powerful, but I’m pretty sure that over half the users would have cards capable of supporting OpenGL 4. It’s been about 4 years since OpenGL 4 first came about, and since then, cards manufactured long before that time have been receiving updates, adding support for it (even if not supporting all of the new extensions).
It’s just one of the things which drags jMonkeyEngine back. I also think it may have something to do with the fact that OS X doesn’t even officially support OpenGL 4 yet.
I didn’t mean to sound like I was ranting. I really do like jME, but I think it should combine it’s approach (not change it’s approach) with that of other engines, so instead of alienating over 50% of the population, maintain backwards compatibility for them, but allow newer features and newer technologies to be used by those who can use them.
Take World of Warcraft, for example. They support OpenGL (for Mac users), DirectX 9 (for those with older GPU’s), and DirectX 11. They actually use the features of DirectX 11, and yet that doesn’t ruin support for DirectX 9 OR OpenGL. That’s the kind of approach that I think would work best for any kind of project like this, and I actually think the shader architecture that jMonkeyEngine has would be absolutely perfect to implement such a system.
Well you can try to forward port the patch from back then, I think it had a few issues but nothing to hard, and put it into the (since then new) community contribution svn, maybee even make sdk plugin for it.
@Empire Phoenix said:
Well you can try to forward port the patch from back then, I think it had a few issues but nothing to hard, and put it into the (since then new) community contribution svn, maybee even make sdk plugin for it.
I will probably do that… Well, except the SDK plugin part (I find the SDK quite hard to work with, feels like an experimental build)
It’s not just about having a patch but having a patch implemented in an engine-friendly way. So whatever solution ends up in will probably require some rework or whatever. I don’t even remember what the down sides were to that original submission anymore.
Also, “SDK plugin” means a way of packaging it so that people who want to try it can simply tick a box and download your app. This makes it easy for others to try it and comment on it.
Presuming you could add geometry shaders ad a separate lib without core engine changes then that would be awesome. And if it does require core engine changes, the fewer that need to be done the better… bonus points if such changes (or ideas for potential changes) would make the engine more flexible for this kind of extension in general.
