OpenGL tesselation NEED TESTERS[DONE+RELEASE+DOWNLOAD]

[devsh]

NVIDIA USERS STICK "#version 400 compatibility" ON TOP OF ALL 5 SHADERS, "tessellation", "vert","ctrl","eval","geom" and "frag"

UPDATE!! - FINALLY FINISHED

Finally there is opengl tesselation shaders natively in irrlicht! I introduced a new function to IGPUProgrammingServices, and reordered the parameters, I think interweaveing shaderfile, shaderentry point and shader compile target is useless, so I decided to do shaderfilenames first then other necessary paramters and then compile targets and entry points (as they are useless in opengl and have default parameters anyway).


I have modified 11.PerpixelLighting to add Tessellation after Parallax Mapping. I wrote a shader you can freely re-use, I am quite proud of the LoD scheme and my method so the triangles don't come apart at seams. I think I messed up lighting a bit as I only dabble in deferred

So anyway there are two versions:

-Precompiled (Linux 32 bit)
http://blooddrunk-game-engine.googlecod ... elation.7z
-Light (have to compile everything)
http://blooddrunk-game-engine.googlecod ... n_light.7z

When compiling remember to use the newest wglext and glxext headers!!! (not the ones which come with irrlicht)

OLD POST:

For those who don't know me, let me say that I'm the guy behind bringing geometry shaders to irrlicht for the openGL drivers. I do not know how many of you use them, but I've found applications for them in Parallax Map fin extrusion and geometry instancing

http://irrlicht.sourceforge.net/phpBB2/ ... sc&start=0





The problem.. ofcourse is that the performance of this is no where near the real thing. So I will be getting a 450 GT at the end of the month, doing tesselation won't take that long. The long process is actually hybrid or someone approving it for the engine. In fact, you might get it with 1.8.0 if I'm quick.

There will be 2 new shader files to provide, patch and hull (dx terminology) a.k.a tesselator and control. These two go between the vertex shader and the geometry shader, this means that a vertex shader for hardware skinning will still work.

What do you think?

[hendu]

Go for it. Personally I'd rather see real instancing integrated first, but that's just my opinion. Like fake tesselating, fake instancing is nowhere near the real thing in performance.

[devsh]

I guess I could do instancing...

[devsh]

could someone update me on how to do the diff?

[3DModelerMan]

Yes, definitely. This needs to go in Irrlicht. I can implement it in the D3D11 driver when I write one, and we could have optional support for the ATI tesselation in D3D9.

[devsh]

No.. ATI D3D9 and OpenGL EXT tesselation is weird and messed up cause you use the vertex shader as the control shader and it is really really messy.

anyway.. as for hardware instancing. I will do the less optimal method where you feed in the transforms in the shader uniform. This is because I'd have to pretty much rape irrlicht, because I'd have to render the world matrices directly to VBO (and no handles for VBOs remember) and attach that as a shader attribute. A lot of messing around that will most probably obstruct quick adoption to 1.8.0.

the new functions are going to be:

Code: Select all

		void drawIndexedTriangleList(const S3DVertex* vertices,
			u32 vertexCount, const u16* indexList, u32 triangleCount, u32 instances);

		void drawIndexedTriangleList(const S3DVertex2TCoords* vertices,
			u32 vertexCount, const u16* indexList, u32 triangleCount, u32 instances);

		void drawIndexedTriangleList(const S3DVertexTangents* vertices,
			u32 vertexCount, const u16* indexList, u32 triangleCount, u32 instances);

		void drawIndexedTriangleFan(const S3DVertex* vertices,
			u32 vertexCount, const u16* indexList, u32 triangleCount, u32 instances);

		void drawIndexedTriangleFan(const S3DVertex2TCoords* vertices,
			u32 vertexCount, const u16* indexList, u32 triangleCount, u32 instances);

		void drawIndexedTriangleFan(const S3DVertexTangents* vertices,
			u32 vertexCount, const u16* indexList, u32 triangleCount, u32 instances);

		virtual void drawMeshBuffer(const scene::IMeshBuffer* mb, u32 instances) =0;

[hendu]

Yeah, that was kinda why I stopped after my quick hack. But to be useful it would need indexed arrays and not the array of uniforms hack.

Especially as some hw supports really low sized arrays, I recall the page [1] that compared instancing methods could not get 32 on AMD.

[1] http://sol.gfxile.net/instancing.html

[devsh]

well yeh, but the least we can do is add these uniform hack. And then add something like,

Code: Select all

stringc attribShaderName="",float* instaceAttribArrayData=NULL, u32 size=0); 

to the parameters of the drawing functions. So then it's optional to use the attrib arrays, it's just that I don't quite get hang of how to do them yet (all the VBOs and stuff).

Also do we upload the attributes every time we draw??? how do we store the transformations as VBO on hardware and only update when they move?

[hendu]

Since it's such a manual process anyway, why not add a setdirty call? Let it be up to the user when to reupload the instanced array.

[devsh]

but that means adding another meshbuffer like thing to the engine

[Qps]

Hi,

This is looking pretty nice. I was wondering what the status of your project is, since your last post was in June.

I would love to use tesselation, will you be releasing some code so we can all play with it?

[devsh]

i just bought a dx11 notebook today.. so i'll get onto tesselation pretty soon

[ACE247]

Woah! Devsh actually BOUGHT a dx11 WINDOWS notebook?
Or did you just rob the store?

[Radikalizm]

Woah! Devsh actually BOUGHT a dx11 WINDOWS notebook?
Or did you just rob the store?

Seeing all the looting going on in some parts of the UK right now this could very well be possible

[ACE247]

If so, Lets just hope you're not that guy I saw on TV today, getting pulled out of his Apartment by the Cops...