I think my main issue here is ownership. The RenderTokens collection I want to pass to my renderer needs to be generic in that they could have come from any model/entity/filter and the renderer won't really care. Its responsibilty is to work through each render token and render it. For this to happen, the rendertoken needs some kind of link back to the entity it belongs to in order to get the mesh but then it also needs to belong to the entity in some form in the first place, I'm not sure I can see how I can get around the cyclic dependency the way my architecture is currently set up.

the link back is required because you don't pass all necessary info in the render token. so you need to link back to the sender to get the rest of the info. your render token is basically identical to my zdrawinfo struct, except instead of containing all the drawing info, its only contains some, or perhaps just the link back to the entity which contains it all. there's nothing really wrong with a link back, it is one way to pass a "pointer" to the drawing info. However the more customary way to program is to pass variables to a subroutine, not a pointer to a data structure owned by the caller. OTOH, you could jut think of it as another from of call by reference, which is what it essentially is. So it looks like your choices are to pass all info in your "render token" or by some other means (call by value), or used the link back (call by reference).

I personally find the Zdrawinfo struct to be an invaluable data structure useful for many things. It was originally created just to pass parameters to the drawlist. but it has since evolved into the preferred way to store drawing info of any type, any where. And it makes perfect sense too. Its a perfect example of "let the task define the data structure". what could be more natural than to store all drawing info everywhere in the game in the format the renderer uses?

Thanks for this, Norm, I'll carry on with it as it is then. It feels like a pretty neat architecture, I was just conerned about the cylclic dependency but it sounds like it's nothing to worry about.