Also for Tess support? The code rests bored in an abandoned folder 
20k*20k map
2 Likes
There’s certainly a cost to supporting more features … it requires the engine developers to maintain it and ensure that it is still supported through the releases. From time to time we find something in the engine that was broken since 2003 but was never fixed because either no-one complained or was using it.
With that said though, it seems there are a lot of useful use-cases for both geometry shaders and tessellation shaders, and the cost with adding them is actually quite low - maybe just an enum here and there, and patching it through in the renderers.
Pretty
ShaderNodes needs more than that, but I guess that’s my part.
For the record. My particular use case was that I wanted to implement face-normal based culling, since enforcing strictly clockwise or counter-clockwise triangle rendering is not an option.
That sounds odd. In what case can you control the normals but not control the winding?
Ok, I wasn’t precise. The vertices are created dynamically by an algorithm along with the normals. I could change the algorithm s.t. the winding would become determinate. Exploiting the fact that I’m getting the normals as a side-product of the algorithm anyway would have been much easier.
Yeah, seems better to generate a proper mesh up front if you can… or even if you can’t, two different meshes, rather than abuse geometry shaders for it.
Your mesh will be faster and run everywhere.
Why “abuse”?
I guess what @pspeed is saying is that the meshes that you’re generating are already invalid, so e.g. exporting them or trying to view them on a GPU without geometry shader support will fail. It is more safe to generate proper vertices in the first place than have the GPU fix them at real time.
What momoko said, but also because geometry shaders weren’t really meant to fix badly formed meshes. Geometry shaders are going to be slower and far less compatible than just spending the extra ‘n’ minutes fixing the mesh generator in the first place. You’ll probably find other improvements in your algorithm in the process.
wana share that abandoned code? 
Since the code is not compatible with any jme version around i don’t see a point of sharing it public. If you only need the Shaders and the *j3md i can upload them somewhere.
After support is available i rewrite the lib and make a plugin out of it. Currently the vegetation and terrain is also mixed up, and i would like to make them separate plugins…
So depending on what you need i can send you the required code…
Don’t know if that is feasible, but there could be a “feature pack” plugin for JME libs that require bleeding edge tech? Something like Android API level?
The core JME team stays with OpenGL 2.0 (so that they don’t have to duplicate efforts for maintaining 2 platforms), and the next-gen stuff can be built with a common base…
Well its all open source, up there is a repo with all the stuff you’d need. The “missing link” is continuity though. Its all hacked stuff that doesn’t help towards integrating it into the main engine branch. Android API levels are a continuous development by one team. This here is all voluntary work by people in their spare time, so I understand that as soon as its about putting in the extra work to make it integrate into the general engine direction and paradigms people jump the ship. But that basically leaves the core team with doing the whole thing over again when they get to implement it, with the added “benefit” of having people go “but its there already, it works, wtf are you doing, sitting on your lazy arses?” 
Contrary to public belief writing software is not removing features from something that can do everything in the beginning, its adding these features, which means a lot of work 
From my point of view the main drawback currently is that there is no difference between a program pipeline and an actual shader program. This makes a clean addition of new stages pretty hard.
Unfortunately i also guess thats its not possible to solve that issue without a redesign of Technique,Shader,ShaderKey and all touching classes. So i guess out of scope for now…
All other solutions are going to be pretty similar to the 'hacked in" community version…
I’ve looked through some forum “hacked” together diffs. What exactly needs to be done to better integrate them into the core engine? What about them is hacked together?
Reason is I’ve been reading some papers on a few different wave and water things, and it all really needs tessellation to be even be worthwhile. If anyone hasn’t seen it, the new UE4 water stuff is really cool. If you already bought UE4 I’d recommend looking through the visual shader editor of it, to get a gist of how it’s done.
/sigh… The problem is not how its done, its doing it. Remember nobody gets money for creating jME, its people doing it in their spare time,
However, if you have read all those papers and know exactly how an editor should look you just need to look into the source of jME, change it and make a pull request for the renderer, shader nodes base code and shader nodes editor, right?
Doing what? The thing @8Keep123 talks about is already done, as I’m pretty sure he’s referring to: Support for geometry and tesselation shaders (diff) - #84 by Empire_Phoenix.
You called these sort of things ‘hacked together stuff’ in an earlier post and that people are basically too lazy to implement it in the engine leaving it to do for the core developers. But if someone like him actually wants to help but doesn’t exactly know what needs to be done (the how in this case), then an answer like ‘The problem is not how its done, its doing it’ won’t help anything.
Taking somebody by the hand and telling him what to do for each step takes about the same time as doing it yourself though. Right in that thread Nehon says whats missing, its not integrated into shader nodes.