It totally depends on what you want to do with your rendering code. The best way to structure your code is to make it flexible so you can choose the right tool for the job at hand. My engine allows for both of the mechanisms that you mentioned, but in my case each object carries around its own material information. The 'state manager' then ensures that there aren't multiple API calls made to set the same data more than once.
The latter of your two ideas is usually called an immediate renderer or something similar. It is generally a higher level object that simplifies the usage of the graphics hardware at the cost of performance.
+1 to what Jason said and or did. Having access to both a typical retained mode , where data is loaded into buffers created and destroyed by the renderer itself, as well as an immediate mode, where you can supply geometry on the fly,is a great boon to debugging("why is this model's lighting not working?, lets draw some normals quick and find out")
Every time I poke through Hieroglyphs source I learn something. Most recently it was how nice creating vertex layouts procedurally from user supplied data is, whereas before I had always had predefined Vertex types defined in the graphics lib that my app had to use. When I'm done, I will have the flexibility to complete define data from outside the graphics lib.
Every time I poke through Hieroglyphs source I learn something.
That is really great to hear - it makes me happy to know someone is getting some benefit from the engine :)
