[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:

Post by Noman »

Got the demo working!

IsoSurf demo showcase thread
(Includes binary demo)

Some notes :
Two hacks are currently in place for the demo to work :
A) Using GL_LINES_ADJACENCY_EX instead of GL_LINES in the glDrawPrimitive call.

B) Fixed a bug in CgProgram::recurseParams when encountering an unknown parameter.
https://sourceforge.net/tracker/index.p ... tid=302997 .

About A :
Important Question

One downside is that I had to hack the GL rendersystem to get this to work.
The primitive that gets rendered has to be GL_LINES_ADJACENT_EX. The question is how do we incorporate the ability to send this to ogre?

Two options :
1) Add the required new possibilities to the RenderOperation enum. This makes sense because these types are becoming generic. See http://msdn.microsoft.com/en-us/library ... 85%29.aspx .

2) Less obtrusive solution. Since these new render operations have no use while not using geometry shaders (Do they?) perhaps a 'Needs adjacency' flag can be added to the geometry shader. Then, when the render system decides on the native primitive type to use, it checks if the pass has a geometry shader. If it does and the geometry shader has the flag turned on, it can send the modified enum value to the draw call.

IMO, if there isn't a reason to use adjacency information unless using geometry shaders, there is no need for the RenderOperation type to be modified.
What do you guys think?

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 »

Moving on, I decided to go for the RenderToBuffer implementation!

I basically finished the required planned phases of the SoC (The final one being creating an impressive demo showcasing geometry shader benefits) so its time to move on to the optional phases. CG support was already done, and I think that this feature is more important than DX10 (tho that is important too) and a geometry shader based shadow technique.

I started laying down the API for the RenderToBuffer object (I plan to take this stage very slowly... This is the first nontrivial API that I'm adding to Ogre...)

Some information that I've collected thus far :
  • RenderToBuffer only streams out vertices (and not indices) in both OpenGL and DirectX. Only the implementation will reflect this, by setting useIndices=false in all the RenderOperations that it fills.
  • The user has to give us four things to prepare a RenderToBuffer operation :
    1. Source renderable
    2. Material to use
    3. Max number of primitives
    4. Output vertex declaration
    I think I'll expose these four params in a rather limited way, for example I won't directly expose the VertexData* object, but rather just the two components that I want the user to set. It should make the object easier to use.
  • The way to have a RenderSystem specific implementation of a feature is to have a manager that is in charge of creating the objects. So, I'll have a RenderToBufferManager and RenderToBufferObject, both with RenderSystem-specific implementations. If the class names are contradicting the ogre naming conventions, please correct me :)
I already started writing the headers, might commit today and start showing the API that I have planned. Not touching the rendersystem (implementation) for now...

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 started laying down the headers for the new classes.
First of all, I changed the name of the class to RenderToVertexBuffer Object/Manager, as we're only outputting a vertex buffer. (I notice ATI uses this name as well).
For those of you too lazy to check out the project (why should you?), here are links to the svn viewer (damn I love svn)

OgreRenderToVertexBufferObject.h
OgreRenderToVertexBufferManager.h

These two URLs will always remain updated with my latest commits.
Besides noticing that my line spacing isn't consistant (thats what you get for copy/pasting from multiple files that arent consistant themselves),
you can see what I have in mind.

I'm thinking of a small C++ trick (inheriting from a SharedPtr to notify the manager of destruction, because I don't want the object to have any reference to the manager).

Besides that, I've left some virtual (and some pure virtual) calls for the implementing rendersystem implementations to implement.

I'm not inheriting from Renderable, because lots of its functions are out of the scope of the buffer that we are generating here. All the object does is fill a RenderOperation structure. The rest is up to the object that uses it.

I'll probably keep refining the headers until the end of the week, hopefully I'll start the implementation then.

PLEASE criticize my design. I don't want it to end up as something that was designed by me for me and won't be used by anyone else.

cloud
Gremlin
Posts: 196
Joined: Tue Aug 08, 2006 6:45 pm
x 14

Post by cloud »

Well I'll certainly be using this, I admired your isosurface demo the other day, very nice.

I don't really know for sure but your SharedPtr idea, I think its a fairly common design, decrease the reference count when you add it to the manager remove it from the manager in the objects destructor. Its certainly less fuss that way.

I liked the header files too, I wonder though, what happens when you attempt to set the same RenderToVertexBuffer on multiple materials, I don't know if this is silly or if it could be like the chaining in a compositor. Another question where you have multiple passes with multiple geometry shaders, not sure how common that would be, but how does it know which geometry dhader to bind to? Maybe a pass name could be added?

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 »

Hmm...

I might pass on the shared pointer trick. Keep it simple, stupid =)
The fact that the object knows about the manager isn't that horrible. (Its not like they are completely coupled...)

I considered using a Pass instead of a Material, but I decided to go with the flow of other ogre classes. I've seen several cases of setting materials when just one pass is wanted, but that is the way. Think forward a bit, in future generations of cards the first generation of geometry shaders might be a fallback technique and not a preferred one.

What do you mean by set the same RenderToVertexBuffer on multiple materials? Each object has a setMaterialName function, so its assigned to just one material at the same time...

cloud
Gremlin
Posts: 196
Joined: Tue Aug 08, 2006 6:45 pm
x 14

Post by cloud »

I just meant the sort of ping pong that goes on in a compositor, reusing the buffer, your design no doubt allows for that.

I know of one example where you "might" have one material with more than one pass with geometry shaders and thats in GPU gems 3 chapter 1. One of the ones I'd like to have a go at that when your done :wink: It'd be done just as easily with multiple scene renders though.
Think forward a bit, in future generations of cards the first generation of geometry shaders might be a fallback technique and not a preferred one.
I think I can see what your saying.

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 »

Ok... I finished the API and (I think) the generic implementation :

OgreRenderToVertexBufferObject.h
OgreRenderToVertexBufferManager.h
OgreRenderToVertexBufferObject.cpp
OgreRenderToVertexBufferManager.cpp

If you see anything wrong with them, please speak up now because it will be harder to make changes once render system specific implementations are up.

My biggest dilemma was about whether certain stuff should be in the generic classes or in the implementations. I want to avoid as much code duplication as I can, but still make sure each rendersystem can actually implement the feature on top of the generic implementation. Hopefully it'll work out (part of my research was looking at the DX10 samples that do Stream-Out, and I think it'll work out just fine).

I'm moving on to the GL implementation now, will probably finish laying out the skeleton today and carry out the implementation for the week.
Time is starting to become an issue, but I'm pretty sure I'll get the particleGS demo port done by August 11th. And if not, the firm deadline is 18th of august, which is even safer.

User avatar
sinbad
OGRE Retired Team Member
OGRE Retired Team Member
Posts: 19265
Joined: Sun Oct 06, 2002 11:19 pm
Location: Guernsey, Channel Islands
x 66
Contact:

Post by sinbad »

I don't think this really justifies it's own manager / singleton - was there a specific reason why you didn't just allow the RenderSystem to create the RenderToVertexBuffer object? If you were just concerned about adding to that interface, I don't think you need to be unless the manager side of the interface gets massively larger.

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 »

Mainly for the auto updating feature...
I want objects to be able to register as automatically updating (similar to animation framework IMO), and I don't think its the rendersystem's job to keep track of all the objects and call their update() method if they registered as such.

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 have a basic demo already written, i plan to implement the API in openGL this weekend.

As for design, I'm considering dropping the auto update support and moving the creation to the HardwareBufferManager (seems to make more sense to me than the generic RenderSystem), in order to get rid of the manager. This is supposed to be a minimalist implementation anyway, so higher level "convenience" features will wait until we try to use the objects and figure out what's good for us.

Still not sure about this move... what do you guys think?

cloud
Gremlin
Posts: 196
Joined: Tue Aug 08, 2006 6:45 pm
x 14

Post by cloud »

A little off topic but has your work so far been tested on other platforms? Or does this follow some time later?

I've tried on a OSX, had the swizzleGLSL working but cg and asm were a white ogrehead on a green background, and IsoSurface was a sort of grid. I thought it might have been a my cg.framework so I updated to the latest, but that did't do 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 »

Sadly I don't have a Mac OSX machine acccessible, so I can't check the problem out.
However, what I can tell you is this :
- The symptoms that you see mean that the geometry shader goes not get run at all.
- It makes sense that if ASM doesn't work, CG won't work either as CG gets compiled into ASM.
This *might* be a driver issue. I really can't help you more. Perhaps you can check the logs to see if anything suspicious comes up?

As for RenderToVertexBuffer :

Progress is coming along nicely.

API Changes :
I am starting to refactor the manager out of the equasion. AutoUpdate support has been canned for now, which means the manager is only in charge of creation. I'll probably move that to the HardwareBufferManager API.

Implementation progress :
OgreGLRenderToVertexBufferObject.cpp
I already have the basic pipeline up and running. I successfully cloned + swizzled the vertices.
I still need to implement two things for this stage to be complete :
1) Using the generated vertices as input for the next stage. This isn't hard, I just need to implement a front/back buffer mechanism as you can't render into the same buffer you're reading vertices from.
2) Dynamic vertex buffer binding. Transform feedback requires seperate code to tell OpenGL which elements of the transformed vertices get written into the vertex buffer, and in what order. I don't fully understand the spec yet in this manner, and I posted about it in the official OpenGL forums : http://www.opengl.org/discussion_boards ... ber=242645 . Feel free to join in the discussion and help!

Stage 2 is a bit tricky, but I hope to have them both implemented by tomorrow. If I don't get an answer from the OpenGL people till tomrrow, I'll just always use glTransformFeedbackAttribsNV until I run into problems.

Time is theoretically becoming an issue, but I already finished the preset requirements for the SoC, this is just an "extra stage". I'd rather finish it all by the end of the SoC, but I don't have a problem with finishing things up afterwards...

As always, feel free to get the code, have a look and comment...

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 »

Small progress update.

I got both of the tasks done and working (Woohoo!)

I was able to dynamically create the attribute binding (in both the GLSL and none-GLSL scenarios) and to recursively generate a vertex buffer from a dynamically generated vertex buffer (I used the swizzle geometry program, and the written primitive count doubled each render).

So, 2 out of 2. The rendersystem side is done.

Except there's a catch.

Ogre uses 32 bits RGBA to store colors. Which is good. However, I don't know how to tell GL how to output my vertex data. Currently it outputs 128 bits (four 32 bit floats) for colors, which is not how we want it. When I try to input 1 as the 'number of elements in attribute', I get one 32 bit float :(

I hope this is solvable. If not, it might mean more core Ogre changes. I'm digging around the OpenGL render system (and asking in the OpenGL forums) to look for answers. GL people. I know you're out there. Help :roll:

Once this is done, however, I'll start porting the particleGS example (which shouldn't be anything more than porting HLSL shaders to CG, .cgfx definitions to ogre .material, and seeding the initial vertex data)

[Edit - I changed the vertex declaration to use VET_FLOAT4 with VES_DIFFUSE in my demo, and everything works perfectly. This means that we won't have to change Ogre's core, but we won't be able to use VES_COLOUR. I want to solve this, but there is an acceptable workaround]

kandhalt
Gnoblar
Posts: 7
Joined: Tue Feb 27, 2007 10:14 am

Testing the geometry shader

Post by kandhalt »

Dear Noman,

We have been testing the geometry shader GSoC extensions and we found some minor bugs. We had a scene with some objects using the GS and others with different materials not using the GS.

These addons make it work:

Code: Select all

void SceneManager::manualRender(RenderOperation* rend, 
                                Pass* pass, Viewport* vp, const Matrix4& worldMatrix, 
                                const Matrix4& viewMatrix, const Matrix4& projMatrix, 
                                bool doBeginEndFrame) 
{
	...
	if (pass->hasGeometryProgram())
	{
		mDestRenderSystem->bindGpuProgramParameters(GPT_GEOMETRY_PROGRAM, 
			pass->getGeometryProgramParameters());
	}
	...
}

void GLSLGpuProgram::unbindProgram(void)
{
	...
	if (mType == GPT_GEOMETRY_PROGRAM)
	{
		GLSLLinkProgramManager::getSingleton().setActiveGeometryShader( NULL );
	}
	...
}

void GLRenderSystem::_oneTimeContextInitialization()
{
	...
	// Check for Geometry Shader Support
	// Enable the extension if it was enabled by the GLSupport
	if (mGLSupport->checkExtension("GL_EXT_geometry_shader4"))
	{
			LogManager::getSingleton().logMessage("Using geometry shader extension (GL_EXT_geometry_shader4).");                        
	}
	if (mGLSupport->checkExtension("GL_EXT_gpu_shader4"))
	{
			LogManager::getSingleton().logMessage("Using shader model 4 extension (GL_EXT_gpu_shader4).");                        
	}
	...
}

void GLRenderSystem::_switchContext(GLContext *context)
{
	...
        if (mCurrentGeometryProgram)
            mCurrentGeometryProgram->unbindProgram();

	...
        if (mCurrentGeometryProgram)
            mCurrentGeometryProgram->bindProgram();
	...
}
Congratulations by your great work! :lol:

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 for the input kandhalt!

I noticed that there were some problems with none-GS objects, I planned to track that bug down after all the devleopment was complete, but you saved me some work :) Thanks!

I'll apply the changes tonight.
For the next times (not just in this project, but in general) its very convenient to just supply a .patch file (very easy to generate when working with tortoise svn). Saves you the hassle of finding all the places where you changed stuff and gives me two-click integration of the changes. For stuff like this it isn't a big issue, but if it was a bigger patch it might've been annoying.

Regardless, its really nice to see that people are using this project's output before it even got merged in the trunk. And it even works! Woohoo!

In other updates -
I started diving into the ParticlesGS sample code, and I think it won't be hard to convert it to Ogre. If I'll have enough time to work on it, I'll finish it this weekend.
GPU only particle systems for the win!

kandhalt
Gnoblar
Posts: 7
Joined: Tue Feb 27, 2007 10:14 am

GLSL - Geometry shaders

Post by kandhalt »

Hi Noman,

I have been testing the usage of GLSL + RenderToBuffer and I noticied two things:

- If in the 'Generate' pass I just declare a geometry program, it complains that a vertex program is needed (with Cg using just a geometry program seems to be ok...).

However, when I declare a (glsl) vertex program, I got the following exception:

Code: Select all

OGRE EXCEPTION(3:RenderingAPIException): Unsupported vertex element sematic in render to vertex buffer in OgreGLRenderToVertexBufferObject::getSemanticVaryingName at ..\src\OgreGLRenderToVertexBufferObject.cpp (line 255)
-If I use a Cg vertex program with the GLSL geometry program, I'm not getting the exception, but no geometry is created. I just got drawn the base object. (With both in Cg VS & GS works ok.)

I can provide you the test code if you want to evaluate 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 »

From the GL geometry shader spec, Issue #20 :
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).
As you can see (bold text), in OpenGL if you use a GLSL geometry shader, you must also use a GLSL vertex shader. I had a dilemma on whether or not to test for these things on my own, or let OpenGL complain (and then catch a glError and throw an exception, etc). I currently decided to let OpenGL complain, because there are many cases, and I'd rather let the driver decide on whats legal and whats not.

As for using CG vertex program with GLSL geometry shader, that is also illegal. I don't know if OpenGL will warn about it (you claim that they don't), but the quote from the spec clearly states that 'north-side' (Geometry+Vertex) must be either GLSL only or ASM (CG is in this category too) / FF only.

The basic GP rules are (according to the spec) :
GLSL GP -> Must have GLSL VP
ASM GP -> Cannot have GLSL VP.

As for the RenderToBuffer. The implementation is still early, but I'd love test cases that already fail, they make my life easier.
The part that is failing is the creation of the output vertex declaration - there is an entire section in the spec on how you should tell OpenGL what it should output.
I currently support only three types of VertexElementSemantics in my output - position, diffuse color and texture coordinates. If one of those is failing, there is a bug in my code.
I will try to add more bindings, however a convention needs to be setup between the rendersystem and the shader creator in this manner (for example, i currently bind gl_Color to diffuse). Should gl_SecondaryColor bind to specular? etc. Or perhaps this needs to be specified by the user. But how do we keep the API not rendersystem specific? *Sigh*

kandhalt
Gnoblar
Posts: 7
Joined: Tue Feb 27, 2007 10:14 am

Post by kandhalt »

You are totally right about the specs requirements.

When I set the "Ogre/GPTest/SwizzleGLSL" material in the ParticleGS, I have the same exception I described in the previous post, using your GLSL vertex program (PassthroughVP.glsl).

In my sample demo I have a custom GLSL vertex shader having the same exception too.

Did you got working the ParticleGS demo with "Ogre/GPTest/SwizzleGLSL" material?

Code: Select all

vertex_program Ogre/ProcEntity/Generate_GLSL_VS glsl
{
	source ProcEntityVP.glsl
}
From (ProcEntityVP.glsl):

Code: Select all

void main(void)																				
{																							
    gl_Position = gl_Vertex;
    //gl_Position = ftransform();
    gl_TexCoord[0] = gl_MultiTexCoord0;
    gl_TexCoord[1] = gl_MultiTexCoord1;
    gl_TexCoord[2] = gl_MultiTexCoord2;
    gl_TexCoord[3] = gl_MultiTexCoord3;
    gl_FrontColor = gl_Color;	
}
Thanks in advance.

P.D: I derived a ProceduralEntity class (like your ProceduralManualObject), using entities instead of using ManualObject, and in it works pretty well.

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 »

Ok. Two things :

1) I applied most of your patches. The only one I didn't apply is the one that logs the in _oneTimeContextInitialization, because the RenderSystemCapabilities already take care of that.

2) I fixed two silly bugs in the GLSL R2VB implementation. First, I originally planned getVaryingName to build a string in stages (with indices etc) but gave up on that, but didn't change all of the code to match (which is why you got the exception). Second of all, the variable name for VES_DIFFUSE should've been gl_FrontColor instead of gl_Color. So, if you now use Ogre/GPTest/SwizzleGLSL as the generating material name it will work.

I'm glad that you got another type of object working procedurally. There was a debate here about how generic this feature should be (IE can you plug it in to any movable object automatically) but I decided to make it a utility class because we don't know well enough how we will want to use this feature.

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 »


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 »

True, but only vs_4_0 and ps_4_0 profiles. No geometry shader profile yet.

It does however, confirm our estimate that cg will feature an HLSL10 cross-translator. It is relatively safe to assume that a gs_4_0 profile will appear sometime (perhaps in 2.1 final? shame that there is no roadmap).

It means that if we add cross-compilation support to ogre (you can currently only compile programs to ASM code, not to other high level languages) we will get proper CG geometry shader support in the future, and the demos from this SoC will run unmodified...

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 »

ParticleGS Demo Complete!

This marks the end of the proper development cycle of this project.

So, until the SoC is complete, I want to iron out the final small issues we still have :

- Adjacency issue. I currently still have a hack to render GL_LINES_ADJACENCY_EX instead of GL_LINES, because I don't have an API to specify it. Unless something changes my mind very soon, i won't add a RenderOperationType, but add a 'requires adjacency information' param to geometry shaders, and the rendersystem will check for its existence when rendering a pass that has a GS.

- Code cleanup (currently have quite a bit debugging code inside that has to go)
- Bugs?

After thats done, I'll start preparing the merge back into the trunk.

Comments?

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 »

Right. Started with the cleanups.

- Added needs_adjacency_information boolean parameter to GpuProgram. If it is enabled in a program, GL render system will use the _ADJACENCY_EXT primitive extension in _render if possible (DX10 rendersystem will do the same). This was the biggest hack in the implementation so far.

- Finished the refactoring of the GLSL specific params, seemed to have forgotten some of that.

- I did have to add a small patch to CGProgram :

Code: Select all

// Shader params need to be forwarded to low level implementation
			mAssemblerProgram->setAdjacencyInfoRequired(isAdjacencyInfoRequired());
Some parameters (like if vertex texture fetch is required) do not get propagated to the generated ASM program. I needed to pass the adjacency flag for the isosurf demo to work correctly.
Am I doing something wrong? Or should the other parameters be forwarded in the same way?

I have some more minor cleanups to do
- Remove debugging code from R2VB implementation
- Understand why I'm getting a GL_INVALID_OPERATION in the setPass in R2VB's update(). Something in the glTexEnvi call. I'd appreciate help on this one, i don't really know why it happens.
- Get rid of RenderToVertexBufferObjectManager (move the single remaining function to HardwareBufferManager)

I think thats it, and we'll be ready for the merge!

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 :

- Removed debugging code from GL R2VB implementation
- Improved erroneous code path detection/handling in GL R2VB implementation.
- Refactored out of RenderToVertexBufferManager. Only the object exists, which is now called RenderToVertexBuffer (no object posfix). HardwareBufferManager is now in charge of creation.
- Dumping the glError after the _setPass in the R2VB implementation. I did not find out why it happens, but everything works fine. There are other places in the code that do this, so I don't feel too bad about it.

These minor tuneups mean that the project is done. Time to get rid of the GS branch and merge into trunk!

User avatar
triton
Greenskin
Posts: 138
Joined: Thu Mar 13, 2008 10:25 pm
Location: Portugal

Post by triton »

Noman wrote:These minor tuneups mean that the project is done. Time to get rid of the GS branch and merge into trunk!
Congratulations. 8)

Post Reply