Sign in to follow this  

Is this a good renderer design?

This topic is 2051 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

[CODE]
class Renderer
{
Renderer(window)
~Renderer()
Create(Buffer/Texture/Geometry/Shader/Material)()
AddDrawable() //something like that, adds a geometry-material pair so the binds can be sorted or something.
DrawFrame()
};
[/CODE]


What i was wondering, is wether i should return handles of some sort and pass them to methods to change them, or if i should return objects that have methods to change themselves (and also contain their ID so you can pass the resources around. I dont want pointers here...)

Anything to improve? Does this design seem like i could later easily edit it to allow for more features (I dont know, multi-pass stuff?)

Share this post


Link to post
Share on other sites
Well, I can't imagine a render system without some pointers (at least internally).. Can you post some example use? that can be more explainatory than example headers.

A design is never bad if is fit your goals and help improve your productivity in some way. You need to ask yourself, what you want be able to do, and what actually you are able to do with that design (without entering in details like maintenability wich you must also consider and is important point if you want to make a medium/big project)

Share this post


Link to post
Share on other sites
I meant not giving the user pointers to the created objects as they are maintained by the renderer and could be.moved for whatever reason. Instead i could have objects wich contain a handle to access their data, so you can call methods on it... I dont really have code yet, trying to get the interface feel good.

Share this post


Link to post
Share on other sites
[font=courier new,courier,monospace]AddDrawable[/font].
Absolutely not. Sorting is not renderer's responsability. Have an higher level component do that for you. You could - at best - sort the mere batches, but I dare you in doing that for arbitrary shaders which might not even have OPOS.
As a side note, if the renderer has a [font=courier new,courier,monospace]Create[/font] call, I guess it might have sense to also provide a [font=courier new,courier,monospace]Destroy[/font] call. At best, the function will be private and each object will de-register itself, or perhaps you'll be clever enough to not care about who destroys hardware resources - personally I have not found this to be viable.

Share this post


Link to post
Share on other sites
As above, I'd at least break the sorting stuff into another layer, e.g.[code]class Renderer
{
Renderer(window)
Create/Destroy(Buffer/Texture/Geometry/Shader/Material)()
Submit(commandList);
};
class CommandList
{
AddDrawable();
Sort();
};[/code]Regarding pointers or handles - it depends on your engine's architecture. I'd lean towards handles, but only if you've got the infrastructure to support it already. Passing pointers back to the user might be easier.

Share this post


Link to post
Share on other sites
I think some sort of a render sequence class would be good, it would maintain the list of commands. So you can have multiple of those and just need to call render(renderSequence) to draw a frame.

I dont really have an engine yet, this is going to be the first part of it.

I think i could split the renderer into a GPU resource manager and have the actual rendering be separate.

Share this post


Link to post
Share on other sites
[CODE]
class Renderer
{
ExecuteCommandSequence(CommandSequence)
SwapDemBuffers()
}
class GPUResourceManager
{
GPUResource CreateXYZ()
}
class GPUResource //Some fancy loosely thought out base class
{
SetData() //Set the data. Maybe also stuff to set part of the data
Upload() //Store the data to gpu
Store() //Idk, something like that. Basically take it away from GPU for whatever reason
}
class Command //If type is lets say shader, it will select it, if type is some geometry (=triangles) it will draw it.
{
Type;
Handle;
}
class CommandSequence
{
*structure to hold commands in oredr user wants*
*hidden from user structure to hold commands in optimized form*
Sort()
}
[/CODE]

Does this seem like a good way to do it?

Now the user can make different sequences to lets say draw the terrain, draw the moving objects or lets say a menu. I think it would work by doing separate calls to executecommandsequence (i need a shorter name for that? but that sounds cool... :P) as you wont probably use the same textures/shaders for GUI and world so i probably wont NEED a way to merge 2 sequences or have a commandsequencesequence class.

Share this post


Link to post
Share on other sites

This topic is 2051 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this