Render Factory?
Author
well... I have planned to re-design my rendersystem, and I have been thinking about thoose factory implementations how would that work with a render system?
this is how I would like it to work (API independent)
RenderSystem - this is the main class wich everything will go trough
RenderCore - this is an abstract base class wich would be derived to the API dependet (the factory?) classes wich will be called to create the API dependent stuff that the RenderSystem will need to display the current Geometry that will be displayed.
Surface - this would be an abstract class that holds the current surface to render on to, e.g. window or texture (or something else?)
and some more stuff that may be needed..
the problem I have now is that I can't figure out a good way to create a surface that the RenderSystem would treat the same but do different things, e.g. render to screen or render to a texture this would need some kind of RenderTarget that would either be a texture or a window unknown to the surface.. but still I can't figure out the relation of them
well I have two different things I have been thinking of
Surface *surface = RenderCore->CreateSurface( 640, 480, 16, 16, RenderWindow );
Surfaec *texturesurface = RenderCore->CreateSurface( 512,512,16,16, TextureHandle );
or
Surface *surface = RenderCore->CreateSurface( 640, 480, 16, 16, ST_WINDOW );
Surface *texturesurface = RenderCore->CreateSurface( 512,512,16,16, ST_TEXTURE );
or does anyone have any other idea of how I should/could do this?
Make RenderContext class from which you derive RenderToTexture and RenderDevice classes (and more if you need).
Also, add methods such as Set() which would each class treat individualy (in DX, replace the back buffer, or in GL set the pbuffer).
Also, add methods such as Set() which would each class treat individualy (in DX, replace the back buffer, or in GL set the pbuffer).
Right you seem to havew the abstraction at a suitable level. Keep your surface representation abstract enough so that ou will be able to implement render to vertex array functionality with multiple inheritance from your vertex array and surface classes.
Creation doesn't need to be done in a factory style. I might be wrong but I don't see any point were you wouldn't know beforehand whether you wanted a texture created or a window - so reflect this in your API i.e. have two seperate functions CreateRenderWindow(640, 480, 16, 16) and CreateRenderTexture(512, 512, 16, 16) that return a pointer to a surface object that you can then pass around. I would probably advise that taking this design you will also want to access the surface as its proper type i.e. as a Texture or Window - so make it easy on yourself and actually return a pointer to the RenderTexture/RenderWindow Object - it can then be passed as a surface pointer to any other parts of the engine that require the general concept of a surface and kept as a regular pointer within a manager for its specific type.
Another thing to consider when implementing render to texture functionality is how to deal with stuff like the creation of cube maps - is a cube map going to be six seperate surfaces or one special surface that knows that it has to generate six views.
Creation doesn't need to be done in a factory style. I might be wrong but I don't see any point were you wouldn't know beforehand whether you wanted a texture created or a window - so reflect this in your API i.e. have two seperate functions CreateRenderWindow(640, 480, 16, 16) and CreateRenderTexture(512, 512, 16, 16) that return a pointer to a surface object that you can then pass around. I would probably advise that taking this design you will also want to access the surface as its proper type i.e. as a Texture or Window - so make it easy on yourself and actually return a pointer to the RenderTexture/RenderWindow Object - it can then be passed as a surface pointer to any other parts of the engine that require the general concept of a surface and kept as a regular pointer within a manager for its specific type.
Another thing to consider when implementing render to texture functionality is how to deal with stuff like the creation of cube maps - is a cube map going to be six seperate surfaces or one special surface that knows that it has to generate six views.
Author
Thank you for your answers :)
I haven't thougth about the cube-mapping issue much, but at first I probibly will use 6 contexts one for each side.. but I want to be able to make one new surface type for cube mapping that holds six TextureHandles one for each size.
I haven't thougth about the cube-mapping issue much, but at first I probibly will use 6 contexts one for each side.. but I want to be able to make one new surface type for cube mapping that holds six TextureHandles one for each size.
Author
another question I have, when to create the different surface classes which would be the "best" solution?
A)
class CSurface {
// just a base class so I can put all different surfaces into one array if needed
...
};
class CTextureSurface : public CSurface, public CTexture {
....
};
B)
class CSurface {
// just a base class so I can put all different surfaces into one array if needed
...
};
class CTextureSurface : public CSurface {
CTexture *m_pTexture; // this is a pointer to the texture which the surface will be rendered to
public:
void BindTexture( CTexture *t ) { m_pTexture = t; }
...
};
well, what would be the differences except that exampel A the surface will be treated as an texture when needed while in B I have to assign a texture to the TextureSurface
A)
class CSurface {
// just a base class so I can put all different surfaces into one array if needed
...
};
class CTextureSurface : public CSurface, public CTexture {
....
};
B)
class CSurface {
// just a base class so I can put all different surfaces into one array if needed
...
};
class CTextureSurface : public CSurface {
CTexture *m_pTexture; // this is a pointer to the texture which the surface will be rendered to
public:
void BindTexture( CTexture *t ) { m_pTexture = t; }
...
};
well, what would be the differences except that exampel A the surface will be treated as an texture when needed while in B I have to assign a texture to the TextureSurface
In my opinion the inheritance solution fits better. A TextureSurface is a Texture it's not a has a relationship. Also consider the problem that Ctexture could be one of many types e.g. a 1DTexture, 2DTexture etc.. Whereas with inheritance you will be directly inheriting from the appropriate type - in most cases a 2D texture.
Don't do this - make CTexture your abstract base class and then create subclasses for each type of texture which implement the appropriate functions. Then create a cubemap surface which renders one particular side of the face - you could then have a function to get the surfaces of the other faces. Basically there needs to be a dependancy between the surfaces so that you can't just destroy one.
Quote:
but I want to be able to make one new surface type for cube mapping that holds six TextureHandles one for each size.
Don't do this - make CTexture your abstract base class and then create subclasses for each type of texture which implement the appropriate functions. Then create a cubemap surface which renders one particular side of the face - you could then have a function to get the surfaces of the other faces. Basically there needs to be a dependancy between the surfaces so that you can't just destroy one.
Author
well.. I could create a CTextureCubeMap from the CTexture base class wich the will be derived into the CCubeMapSurface or would that be a bad idea? the CTextureCubeMap would contain 6 CTexture2D (or just CTexture) then it would have a function to retrive them side by side.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
