Jump to content

View more

Image of the Day

Working on an auto spawn system. #gamedev #indiedev #screenshotsaturday https://t.co/Mm2kfekz7b
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.

Sign up now

Design of a modern data driven renderer

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.

  • You cannot reply to this topic
3 replies to this topic

#1 uglybdavis   Members   


Posted 10 September 2012 - 06:13 PM

Hi guys.
I'm trying to create a modern rendering system, trying being the keyword. I want to make something that is API independent and data driven. All my research points me in the direction of using render lists. I can somewhat comprehend what is entailed, but ownership confuses the crud out of me. I'm a tools programmer, graphics is something i'm aware of but i can't remember the last time i wrote a shader. Please bare with me as some of this is going to be described a bit higher level than i would like to.

So i have a GameObject which contains a RendererComponent. The RendererComponent owns a RenderCommand and a Material. The material contains a shader, and all the variables (textures, matrices etc…) that the shader needs. The RenderComponent is responsible for filling out the RenderCommand based on it's material.
[source lang="cpp"]class RenderCommand { Independent VBO; u32 numTriangles; u32 numVerts; // topology? // kvp for shader values? // Blend mode};[/source]
Obviously i want rendering to batch based on MaterialState rather than having to make one draw call for each object.
To achieve batching i have each camera own a list of RenderCommands, this is of course filled with objects visible after all sorts of culling.
After the render commands have been queued up, sort them based on material, and material properties to avoid state changes where possible.
The game Renderer has an ExecuteRenderCommand function, that takes a render command as an argument. Lets assume the implementation (OpenGL, vs DirectX) is loaded from a dll.
Finally submit the RenderCommands to the Renderers ExecuteRenderCommand function

First question, Am i even in the ballpark with this? I was not able to find any information on making a data driven renderer with RenderCommands.
Are there any good articles / books / online resources on the topic?

I'm also thinking about making RenderCommand abstract and subclassing it to VBORenderCommand, DisplayListRenderCommand, etc… Enabling some higher level system to choose which command to use based on the device the code is running on. Any objections to this? Maybe a better approach?

Should i abstract RenderCommand away from the RenderComponent? Something like
[source lang="cpp"]foreach(gameObject in visibleObjects) camera.renderCommands.add(gameObject->renderComponent->FillCommand(new RenderCommand()));[/source]

where FillCommand returns the argument that was passed in?

All of the above code is assuming that i'm going to be passing pointers to VBO's around. Is there any instance where making a new VBO and copying over the source data would be benefitial?

Again, i'm a tools programmer, so this is all new to me, sorry if the questions are dumb.

Thanks so much for taking the time!

#2 kd7tck   Members   


Posted 11 September 2012 - 02:39 AM

Look at this post http://www.gamedev.net/topic/630029-data-driven-renderer/ .

This is a lot of work, why are you doing this?

GameObject->RendererComponent->RenderCommand->Material->(textures, matrices etc...)?

Model your system after the collada file format, this will make it easier for you to import data later.

#3 Hodgman   Moderators   


Posted 11 September 2012 - 03:39 AM

This is a very long thread from last year, but might be of interest: http://www.gamedev.net/topic/604899-frostbite-rendering-architecture-question/

#4 uglybdavis   Members   


Posted 11 September 2012 - 04:09 PM

@kd7tck Thanks for the tip, looking at the file format right now.

@Hodgman I don't know how i didn't find that thread. thanks, it's exactly what i was looking for!

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.