[GSoC 2008 - Accepted] Add geometry shader support

Threads related to Google Summer of Code
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

[GSoC 2008 - Accepted] Add geometry shader support

Post by Noman »

(This is the abstract submitted to GSoC)

Keeping up with the latest in bleeding edge technologies is a tough task in the 3d rendering world. New technologies are being developed, which require a state-of-the-art 3D engine to be in constant development in order to keep up. I would like to help the Ogre project keep up with the pack by adding in support for geometry shaders.

One of the biggest changes in the DirectX 10 / Shader Model 4 generation is the introduction of Geometry Shader support. Geometry shaders open up new opportunities for developers to perform operations that were used to be only possible in the CPU. Some examples of the possibilities include shadow volume extrusion ( http://msdn2.microsoft.com/en-us/librar ... S.85).aspx ), single pass render-to-cubemap (http://msdn2.microsoft.com/en-us/librar ... S.85).aspx ), GPU only particle systems ( http://msdn2.microsoft.com/en-us/librar ... S.85).aspx ) and many more.

With support for the new generation of shaders already out for both DirectX and OpenGL (Ogre's main render systems) it seems like the perfect summer to add geometry shader support to Ogre.

I believe that the project is an ideal SoC project in terms of its relevance and scope. I have already talked about its contribution to the Ogre project. I will now present my proposed roadmap for the project in short.

Stage 1 [Done] : Add geometry shader support to the GpuProgramManager and Pass, so that the render system gets the information.
Stage 2 [Done] : Add geometry shader support to the OpenGL render system. The GL render system has been selected because only DirectX10 supports geometry shaders, and the DX10 render system is still in early stages.
Stage 3 [Done] : Create a basic demonstration application which uses a geometry program.
Stage 4 [Done] : Add geometry shader support to Ogre's scripting interface. Geometry program declaration in .program scripts and referencing in material definition.
Stage 5 [Done] : Add geometry shader support to the CG program manager, enabling cross-rendersystem geometry shaders (in the future, when the cg compiler will support them all).
Stage 6 [Done] : Create more advanced geometry shader examples, using the scripts for their definitions this time. This set of examples should be reusable in real-world scenarios.
Stage 7 : Add geometry shader support to the DX10 render system. The render system is not part of Ogre's core distribution yet, so this is of lesser priority.
Stage 8 [In Design] : Add a RenderToBuffer API to Ogre.
Stage 9 : Implement the RenderToBuffer API in OpenGL.
Stage 10 : Create a sample that demonstrates the use of the RenderToBuffer API.
Last edited by Noman on Sat Jul 19, 2008 12:59 pm, edited 7 times in total.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post by tuan kuranes »

Interesting application.
What shader language are planned glsl, cg, hlsl if dx10 ready or just cg ?
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Post by Noman »

Since the GL render system is first on the list, GLSL will be first on the list as well. HLSL4 support will come in if the DX10 render system comes through. CG is a problem because I think that the current version of the CG compiler doesn't support DX10, so its basically abstracted GLSL currently...
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post by tuan kuranes »

CG is a problem because I think that the current version of the CG compiler doesn't support DX10, so its basically abstracted GLSL currently...
It will surely support hlsl4* profiles soon at some point. It's like the fact that OpenGL geometry shaders are Nvidia only for now, but will surely be supported by other vendors...
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Post by Noman »

You have a valid point, but I still believe that it is currently relatively not important.

Today, if you write a geometry shader in CG you get no advantage over GLSL besides future compatibility. That is a real advantage, but my aim is to deliver a sealed contribution to Ogre.

If I add cg support, someone will need to add in DX10 geometry shader support to the CG program manager later on. I didn't look at NVIDIA's roadmap for cg, but there might be future changes seeing as DX10 only supports HLSL (no assembly). CG currently generates assembly shaders, so there might be some changes when DX10 support is added to it.

I'd rather see what they do before I decide what I do, so I don't think that the time is right for cg support right now.
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post by tuan kuranes »

CG currently generates assembly shaders
Latest CG has DirectX 9 profiles (hlslv and hlslf) to cross-translate Cg to HLSL, (and glslv glslf profiles too).

Note that I agree with you about implementing glsl/GL only for now, aiming at finishing geometry shader first.

But you have to explain why you discarded CG at some point, and even why not even trying CG once glsl finished. (using condition-based planning, if DX10 finished, if CG estimation work small, etc...)
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Post by Assaf Raman »

tuan kuranes wrote:
Noman wrote:...CG is a problem because I think that the current version of the CG compiler doesn't support DX10, so its basically abstracted GLSL currently...
It will surely support hlsl4* profiles soon at some point. It's like the fact that OpenGL geometry shaders are Nvidia only for now, but will surely be supported by other vendors...
Have a look here: http://developer.nvidia.com/object/cg_toolkit.html
New OpenGL profiles (gp4vp, gp4gp, and gp4fp) for GeForce 8 extensions
These expose new DirectX 10-class features including geometry shaders, bindable constant buffers for uniforms, texture arrays, first-class integer support and more
New Profiles:
p4vp, gp4gp,gp4fp - runs with OpenGL on GeForce 8 series.

Still no DX10 support - that is true - but geometry shaders support exists.
CG is more like HLSL4 then GLSL.
Watch out for my OGRE related tweets here.
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Post by Noman »

I decided to add CG support as a potential stage in the later part of the project. It probably won't take too much time, and is a nice tagline to add to the finished product. Will probably have a bigger user base than the shadow technique, so I placed it just before it.
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Post by Noman »

The proposal got accepted! Rejoice!

Now I have a question for the community - which samples would you like to see working in Ogre? I already have a simple one for stage 3 of the project (which is for testing purposes, not showcase), but what are the coolest demos you've seen that use this feature?

I'm currently mainly thinking about the DX10 Shader Model 4.0 workshop ( http://msdn2.microsoft.com/en-us/library/bb172502.aspx and the NVIDIA OpenGL 10 SDK samples ( http://developer.download.nvidia.com/SD ... mples.html ). Has anyone seen a really impressive demonstration outside these two?
User avatar
tuan kuranes
OGRE Retired Moderator
OGRE Retired Moderator
Posts: 2653
Joined: Wed Sep 24, 2003 8:07 am
Location: Haute Garonne, France
x 4
Contact:

Post by tuan kuranes »

In the DXSDK the particleGS sample, wins because of its simplicitiy and usefulness.

In ATI samples, the 'Global Illumination' one seems very interesting but may need more advanced DX10 rendersystem code and much more work...
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Post by Noman »

Coding time started so I started laying down the framework.
I already did pretty much all of the API stuff (defining the new program type, adding it to passes etc). Some code cleanup was required in existing code that assumed there were only two types of programs.

Things like

Code: Select all

programType == GPT_VERTEX_PROGRAM ? (vertex shader code here) : (pixel shader code here)
don't work anymore and need to be changed to a switch/nested if.

I'm done with the first part and will probably commit the first batch of changes this weekend (need to make sure that spacing is consistant etc).

Also started work on the GL Render system support + basic demo.
I already correctly report whether or not the card supports geometry shaders, and started implementing the GL-specific calls along the pipeline.

My current uncertain point is how to handle the fact that when linking geometry shader programs, the input and output primitive types (ie triangle list, triangle fan etc) have to be specified explicitely.
Should I take the input from the render operation? Should the output be pre-specified in the vertex program? Haven't fully decided yet.
I'm actually currently leaning towards having the user give me both, just to be more strict, as when you write a geometry shader you know what primitives you are dealing with, so you can supply this information yourself (that also allows us to warn/throw exception when the input doesn't match instead of running a shader that will likely produce garbage)

Opinions?
User avatar
Assaf Raman
OGRE Team Member
OGRE Team Member
Posts: 3092
Joined: Tue Apr 11, 2006 3:58 pm
Location: TLV, Israel
x 76

Post by Assaf Raman »

Noman wrote:Should I take the input from the render operation? Should the output be pre-specified in the vertex program?
This is a good question, we have to see it also in the scope of d3d10 - this is a gl specific problem… In hlsl4 this data is part of the shader code.

Well, I think that the best option I can see is to have this data as new parameters to the ogre high level shaders, I think you should add the following parameters: maxVertexCount, geometryOutputType, the input type should be as you suggested – based on the render operation. I will be happy to see what Sinbad thinks on this issue.

On a different matter, well, I saw that that nvidia has a nice emulation driver called NVEmulate that can emulate geometry shaders on older NVIDIA hardware. That is good news for anyone that will want to see your work has an older GPU.
I found instructions on how to use it here: https://agora.cs.uiuc.edu/display/graph ... ello+World
(Look for “Emulating Geometry Programs on Older Cardsâ€
Watch out for my OGRE related tweets here.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

I agree - since (I assume) most geometry programs are going to be written with a specific primitive type in mind anyway, it's probably better to localise the dependency on this type by making it a parameter to the geometry shader definition. If someone comes up with an example where it's more useful for the goeometry shader not to be tied to this, we may have to rethink it but I think it's the best start, rather than having to pull in extra information from the renderop, which is separate. You could (should?) of course validate the renderops being executed are compatible with the expected type of an active geometry program.
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Post by Noman »

Short progress report :

I've comitted the first batch of changes, mostly to the Ogre::Pass API, as well as some references to it in the scene manager, render system capabilities etc. I think I'm done with part 1 of the project, but there might be some small references missing. I'll probably find them before finishing stages 2+3.

As for the OpenGL implementation and first sample. Didn't commit most of this work yet, but I created a small Demo that runs a geometry program that multiplies each triangle and swizzles the x and y axes. This demo will probably NOT make it to the final merge with Ogre Head (maybe I'll add it to the playpen) as it is merely a test for my OpenGL implementation - its not meant to be impressive visually.

As for the implementation itself, its coming along nicely. I decided to be strict with the geometry shader declaration - both input and output primitive types will have to be specified. Shader compilers that include this information in the shader code (HLSL4 for example like Assaf mentioned) can fill this information automatically when compiling the program.

I hope to see the first visual signs of geometry shaders working either this weekend or during next week.

Stay tuned :)
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Post by Noman »

The GeometryShader example has now been added to my branch's SVN. Not working yet, but I'm working hard on finding all the small places where shaders are referenced in the GL render system (and occasionally finding another spot in OgreMain). I think I'm pretty close already, hope to get the sample working today or tomorrow.
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Post by Noman »

Big update!

Geometry shaders are showing first signs of life!

Image

(Don't mind the FPS, its in debug mode)

The program that is being used currently sets the output color to red, emits a primitive, then swizzles the x and y values, changes the color to blue and outputs it again. So the blue ogre head in the bottom right is one generated by the geometry shader.

There is much more work to do before this stage is finished though - I currently have a hack in OgreGLSLProgram to set the input and output primitive types to triangle list (instead of getting them from the GpuProgram like discussed earlier) and the program parameter pipeline is not 100% complete yet.

However, it shows that I'm getting somewhere...

If anyone wants to give it a try, the code is in the SVN repository (soc08-geomshaders branch).
User avatar
PolyVox
OGRE Contributor
OGRE Contributor
Posts: 1316
Joined: Tue Nov 21, 2006 11:28 am
Location: Groningen, The Netherlands
x 18
Contact:

Post by PolyVox »

Excellent work! I have some uses for geometry shaders so I'm keeping an eye on this thread :)
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Post by Noman »

Thanks!

Moving on, my next step is to get rid of the hack that hard codes the primitive type to triangle list.

We already have program-type-specific parameters in GpuProgram (mSkeletalAnimation, mPoseAnimation etc). The question is what will be the type of the mGeometryInputPrimitiveType and mGeometryOutputPrimitiveType. The natural choice would be RenderOperation::OperationType, but I'm not sure.

The geometry shader gl spec (http://www.opengl.org/registry/specs/EX ... hader4.txt , section 2.16) mentions five input primitive types :
Points (POINTS), Lines (LINES), Lines with Adjacency (LINES_ADJACENCY_EXT), Triangles (TRIANGLES), Triangles with Adjacency (TRIANGLES_ADJACENCY_EXT).

Points, lines and triangles map perfectly to OT_POINT_LIST, OT_LINE_LIST and OT_TRIANGLE_LIST, respectively.
I think that Lines with Adjacency maps to OT_LINE_STRIP.
The triangles with adjacency is the one im unsure about. Do both OT_TRIANGLE_STRIP and OT_TRIANGLE_FAN map to that? I think so, but I'm asking here to make sure that I'm reading the spec correctly.

The output type is easier, being either OT_POINT_LIST, OT_LINE_STRIP or OT_TRIANGLE_STRIP.

Actually, writing this post caused me to read the spec carefully enough to be pretty sure that I read it correctly. The wonders of explaining your problems to others :)
User avatar
Frenetic
Bugbear
Posts: 806
Joined: Fri Feb 03, 2006 7:08 am

Post by Frenetic »

I have zero experience with geometry shaders, but I don't think OT_TRIANGLE_FAN maps to TRIANGLES_ADJACENCY_EXT. This was the impression I got from Figure 2.X3 in the spec, and from the paragraph below the figure, which was:
Triangle Strips with Adjacency

Triangle strips with adjacency are similar to triangle strips, except that
each line triangle edge has an adjacent vertex that can be accessed by a
geometry shader (Section 2.15). If a geometry shader is not active, the
"adjacent" vertices are ignored.
Emphasis mine.

Hope I'm being helpful, and keep up the good work! :)
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

Excellent work - already well on the way!
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Post by Noman »

More progress...
Longer post this time. Have some questions in bold, OpenGL natives please help :)

I added three members (and getters/setters) to OgreGpuProgram - maxOutputVertices, inputOperationType and outputOperationType. (Using operationType instead of primitiveType to be consistant with Ogre's terminology).

OgreGLSLLinkProgram now uses them to set the appropriate parameters in activate(), and it works fine.

Also finished up the final missing pieces of the puzzle in the parameter pipeline, and this appears to be working as well (the orig and clone colors are parameterized in the demo).

Some decisions :
The mapping between operation types and primitive types is up to the render system. If an illegal parameter is given, the rendersystem will throw an ERR_RENDERINGAPI_ERROR. See GLSLLinkProgram::activate.

My final task before I declare step 2+3 as finished is to get assembly shaders working.

Which brings me to my next point of uncertainty (I need to find a better name :) :

Once again, a quote from the holy bible erm gl spec.
20. Now that a third shader object type is added, what combinations of
GLSL, assembly (ARB or NV) low level and fixed-function do we want
to support?

DISCUSSION: With the addition of the geometry shader, the number of
combinations the GL pipeline could support doubled (there is no
fixed-function geometry shading). Possible combinations now are:

vertex geometry fragment

ff/ASM/GLSL none/ASM/GLSL ff/ASM/GLSL

for a total of 3 x 3 x 3 is 27 combinations. Before the geometry shader
was added, the number of combinations was 9, and those we need to
support. We have a choice on the other 18.

RESOLUTION: It makes sense to draw a line at raster in the GL
pipeline. The 'north' side of this line covers vertex and geometry
shaders, the 'south' side fragment shaders. We now add a simple rule
that states that if a program object contains anything north of this
line, the north side will be 100% GLSL. This means that:

a) GLSL program objects with a vertex shader can only use a geometry
shader and not an assembly geometry program. If an assembly geometry
program is enabled, it is bypassed. This also avoids a tricky case -- a
GLSL program object with a vertex and a fragment program linked
together. Injecting an assembly geometry shader in the middle at run
time won't work well.

b) GLSL program objects with a geometry shader must have a vertex shader
(cannot be ARB/NV or fixed-function vertex shading).
I don't know OpenGL that well, so I'll say what I think I understand and please correct me if I'm wrong :
They say that if you have a geometry shader you need to have a vertex shader. I think that by saying 'shader' they mean high level shader (as opposed to assembly program), which is quite funny terminology.

This means that these are the legal combinations of 'north side' shading combinations that have geometry programs :

Fixed Function + ASM
ASM + ASM
Shader + Shader.
(Question : Am I Right?)

In my demo I only covered the third option.


My next step will be to get the first two options working.
I compiled a cg version of the swizzle shader in cg compiler and got this :

Code: Select all

!!NVgp4.0
PRIMITIVE_IN TRIANGLES;
PRIMITIVE_OUT TRIANGLE_STRIP;
VERTICES_OUT 6;
# cgc version 2.0.0015, build date May 15 2008
# command line args: -profile gpu_gp
# source file: gs_simple.cg
#vendor NVIDIA Corporation
#version 2.0.0.15
#profile gpu_gp
#program geometry_swizzle
#semantic geometry_swizzle.position : POSITION
#var float4 position.__data[0] : $vin.VERTEX[0].POSITION : HPOS[0][32] : 0 : 1
#var float4 position.__data[1] : $vin.VERTEX[1].POSITION : HPOS[1][32] : 0 : 1
#var float4 position.__data[2] : $vin.VERTEX[2].POSITION : HPOS[2][32] : 0 : 1
ATTRIB vertex_position = vertex.position;
TEMP RC, HC;
MOV.F result.position, vertex[0].position;
MOV.F result.color, {1, 0}.xyyx;
EMIT;
MOV.F result.position, vertex[0].position.yxzw;
MOV.F result.color, {0, 1}.xxyy;
EMIT;
MOV.F result.position, vertex[1].position;
MOV.F result.color, {1, 0}.xyyx;
EMIT;
MOV.F result.position, vertex[1].position.yxzw;
MOV.F result.color, {0, 1}.xxyy;
EMIT;
MOV.F result.position, vertex[2].position;
MOV.F result.color, {1, 0}.xyyx;
EMIT;
MOV.F result.position, vertex[2].position.yxzw;
MOV.F result.color, {0, 1}.xxyy;
EMIT;
END
# 18 instructions, 0 R-regs
As you can see, the output includes our new three parameters, which means that GL (hopefully) won't need them manually from us.

But, since this is still part of a GLSL program object (Question for GL people - is it possible to use shaders/programs in opengl without these program objects?) it will still go through the activate() call, which will need the input from the user. I will have to deal with this (either in the activate() call by checking if its GLSL or assembly or by getting these values and filling them into the OgreGpuProgram automatically).

One small question - the line

Code: Select all

!!NVgp4.0 
Means that the native OpenGL profile name for this assembly program is NVgp4.0 ? (For rendersystem capability reportings etc)[/b][/code]
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

Yes, in GL there have been 2 classes of GPU programs, the original 'ARB' shaders which were in assembler, and then later GLSL. Assembler programs do not use unified (linked) program objects like GLSL does, they have separate vertex and fragment pipes with fixed attributes mapped between then. GLSL in contrast has an arbitrary number of programs which are linked into a unified 'program object', and all the connections (say, between vertex and fragment programs), is resolved at 'link' time, just like a C program.

I've personally never combined assembler and GLSL in one render, although I have rarely used fixed function and GLSL. This is only possible if you use built-in attributes to link between the stages, rather than arbitrarily named 'varying' attributes which happen to agree both sides of the divide. I'm sure the same limitation would apply to using assembler shaders with GLSL too.

What they're saying is that if you use GLSL for the vertex shader, you have to use it for the geometry shader and vice versa. The same applies for assembler shaders (obviously fixed function isn't an issue).

I wouldn't worry about it too much - concentrate initially on GLSL because that's what most people use. Those using Cg might compile geometry shaders down to assembler since we don't support compiling Cg to GLSL yet, so it would be nice to support it, but I wouldn't be devastated if we had to come back to that later.
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Post by Noman »

I'd agree and move on to the next stage (scripting interface), but I'm a bit worried.
CG currently only has glslv and glslf profiles - no glslg profile, so you cannot use cg geometry shaders with the glsl pipeline even if we did support cg compiling to another high level language. I don't know if NVIDIA plans to add this profile (might be a good idea to ask them, I'll probably do that) but I do plan to add CG support during this SoC, which means I have to add assembly shader support.

I also want to try to avoid hopping between different stages of the project as much as possible. If I'm not adding support for assembly shaders, I'm done with the GL render system but will have to revisit it when I add CG support, which is something I'd like to avoid. I'm rather familiar with the GL codebase currently, so I think finishing the assembly shader pipeline is the next thing I will do.
User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19269
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

Whatever works best for you, you have lots of time left so if you feel more comfortable that way then go for it. I was merely trying to save you the pain of dealing with assembler shaders at this early stage ;)
User avatar
Noman
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 714
Joined: Mon Jan 31, 2005 7:21 pm
Location: Israel
x 2
Contact:

Post by Noman »

Got assembly shaders working!
Most of the job was reading to understand exactly what OpenGL expects to get, and of course, didn't work in the beginning because of more minor functions in ogre that i didnt add the GPT_GEOMETRY_PROGRAM reference to.

Anyway, here is the obligatory screenshot :

Image

I used the same program except for two changes :
1) Colours arent parameterized.
2) Emitting points instead of triangles. This is because for some reason the ENDPRIM instruction isn't doing its job, and the two triangles are connected. But I assume its just bad shader coding on my part, so I'm not bothered by it.

I think that this marks the end of part 3 of the project, and I will now move on to the scripting interface.
Of course, updated source code is in the SVN branch...

Does anyone think I'm missing something? (Before I move on)
Post Reply