Hi, I’ve been wondering what the current state of support for geometry shaders in JME3 is. On the one hand I’ve read a forum post from 2014 that it is planned but not implemented yet. On the other hand it seems that it has already been used, e.g. here. I’m a little confused about this.
I’ve looked into the sources and noticed that there really is some commented-out code on geometry shaders included in LwjglRenderer.java. To me it looks like someone has been playing around with geometry shaders but hasn’t finished it.
So what do I need to do to get a geometry shader compiled into my material?
I’m sorry, I didn’t link the actual post but only the thread. I’ve updated the link now: It’s only a side note, but obviously geometry shaders have been used with JME3?
Hmkay, thanks for this information. Out of curiosity, you do not know any patches or something that would enable geometry shaders, or when they are planned to be implemented officially, do you?
I don’t know. The author of the linked post is still around, I guess. Maybe he put out a patch or something.
Not sure what the priority is for it in the engine as it’s a bit outside of my wheelhouse. Like instancing (which did finally make it in) it’s one of those things where the number of people who think they need it vastly overshadows the number of people who actually need it. And I guess so far none of the core developers has had a requirement for it, personally.
I’m not saying it’s not needed… just explaining why it’s not on anyone’s direct path.
As paul already said, in 90% of cases you don’t save processing power but gain a bit of comfort. That however might change when real 3d support is needed in the future (Oculus and so on). But even for that it would require a bit more changes.
I say it should because i used it in august 24. So all newer changes are not yet pushed. Even if its based on a patch i adopted from someone else long time ago, credits for this branch belong to Perjin
If we add it, what will it be used for within the engine or what is it expected to be used for?
It will not be supported for a large portion of GPUs - more specifically mobile GPUs. Are the gains associated with geometry shaders outweigh the proportion of people who will not be able to use them?
So for the answers to those questions has been “No”. Perhaps if we were to have official Oculus Rift or 3D stereo support that answer change.
I personally have the opinion that it is never a bad thing supporting stuff. Even if it is not used within the main jme features, users who want use it can use it without modifying the sources. I quite don’t see to point of delaying support for features just because the core features don’t yet require it.
The responsibility for targeting your customers systems should be done by the user. It is now a minor problem having always fallbacks for every little feature, but that might change, unless jme never intends to support any gl3.3+ features. So at some point there will be a split, use feature x, and your customers required a gl4 card.
//Add: I really think that 3D stereo is going to be an important topic in the next years.
I do share @zzuegg’s point of view. In my opinion the two questions you @Momoko_Fan mentioned are of less relevance:
Just because a feature is not used within the framework itself or not available on every plattform doesn’t mean the feature is not required. Geometry shaders have been around since OpenGL 3.2, which was first supported by hardware back in 2009 I think. If JME claims to be state of the art – it does according to the article on the German Wikipedia at least – than one has to state that it fails this demand considering support for this fundamental technology.
I have one use case, but not sure it’s really worth it. I can be used to render PSSM shadow maps faster.
see http://http.developer.nvidia.com/GPUGems3/gpugems3_ch10.html
look for “Using Geometry Shader Cloning”
Sounds pretty neat at first glance, but it actually only reduce overlap of the splits IMO, and avoid some drow calls. IDK…
Well you guys may not realise that the change is not as trivial as it sound.
I never applied any of the patches proposed because they were incomplete.
I guess they were enough to have it work in specific cases (probably for the use cases of people proposing the patch) but not from an engine point of view.
It’s never a bad thing to support stuff, but it’s an utterly bad thing to half support stuff. Because the minute you share it, here comes the guy with that use case where it doesn’t work.
I’m not saying we’ll never have them, I’m saying that implementing them is an investment and for now, it didn’t appear to be worth the hassle.
*Render to cubemap could be implemented as singlepass
Agree that the patches where never intended as ‘pull requests’ at least the one i made.
To be real useful the ‘multi viewport’ and multi layered FBO targets would be needed to add also.
Beside that, i am hoping more for tessellation shaders At least for terrains, nothing beats them…
Also since we are talking here, it would help me already a lot if the required enums are added to the core. Then at least i could make my terrain implementation ‘jme3 vanilla’ compatible. Since currently its not possible check for geo+tess support at runtime…
Nah, its my own terrain implementation. no need to add sploreg
I am referring to the Enums to identify the shaders, or GL4 for example. Nothing terrain specifiy. Just beeing able to use my own modified branch to develop, while still beeing able to compile and use the fallback on vanilla.
I passed just a iso grid and the heightmap to the shader, generating the quads based on terrain normals and camera distance is done on the gpu. Again not saying this could not be done without geometry shaders, but it makes it very easy to do
At least for terrains, nothing beats them…
