First off, thanks to those who take the time to read through this. My current design is little more than a wrapper for d3d and managers/caches for resources(textures/fonts/meshes/shaders/etc) I've come a long way from a single triangle on screen, and if I had any time to really work in blender, I'd probably have a few really nice demos to show off (with planar reflections and shadow volumes)

My current demos' render loops are typically something like this:

beginscene;set up states;set shader;render model(sets textures, and grabs vertbuffer of mesh needed, then calls dip)set another shaderrender another modelset yet another shaderrender gui treeend scene.

This allows me to do pretty much what i want in each demo, but i have to worry about shaders/states far more then i would like, and things like shadows/reflections need to be handled for each object drawn. One reason for this is that my vertex structures are hard coded. So...

#1 I'd like a little guidance on how the shaders can dictate the vertex format, as opposed to the vertex format dictating what shaders can be used(and requiring the user to set them up each frame)


I'm thinking of composing a queue of rendercalls, perhaps created from a scenegraph, which will allow sorting of calls by shader, material, texture etc, and also build instanced dip calls where possible. so a command would contain a mesh, shader, material params, and a world transform, and flags for whether or not the object is a shadow caster, or emits light, is alphablended, etc

#2 Does anyone have any advice for implementing such a system, or see any pitfalls that i might encounter?


I can't think of anything more to ask atm, but will return when i do... in the mean time, thanks again.

[edited by Phantom: removing code tags to stop long text segments breaking forum layout]

[Edited by - phantom on December 27, 2010 1:36:39 PM]

Krohm, thanks for the lead on GOW, I found this at Christer's blog.

Quote:
Yes. Please make extra special sure you have a clear idea of what you need to support and what is your goal. Trying to support "arbitrary" shaders will drive you crazy.

That's what this thread was about, coming up with a solid plan for supporting my wishlist for this version of the renderer, and finalizing the wishlist into a set of specifications. As far as where to handle instancing, ie: game vs engine; I plan on testing this on multiple machines to get a baseline of when it's advantageous to instance, and then allow this value to be adjusted to the client computer.