"Mesh" should be an interface or an abstract class?

Started by
31 comments, last by swiftcoder 11 years, 6 months ago
I love the example given there.
A real render function would likely need a "material" as a parameter too though?
I'm wondering how you'd go about representing this.

struct Material
{
VertexShader* vertexShader;
PixelShader* pixelShader;
... shader parameters ...
}


How would you represent the shader parameters though as they are likely to be different for each shader and the render() code shouldn't really have to know what paramaters exist and are required to be set for each different type of shader should it?

In my older code the display objects are responsible for drawing them selves (which is what you are avoiding here) so it's a lot easier to know that an "Animated3dModel" sets a specific shader on the device object and it already knows what that shader requires so can set the parameters directly. It's not so clear to me how to communicate all this in a RenderOperation object.
Advertisement


You definitely have a solid foundation then. Three years of C++ is much more than most people try to start with. Just out of curiousity, what books did you order?

Anyway, you will find that there are a lot of nice people here who will dedicate their time to helping you and answering your questions even though they aren't getting paid to do so. That's what Gamedev.net is all about. This community has given me so much help and guidance over the years that I owe it back to others who need help. Feel free to pm me anytime if you need help or have questions. For the time being, at least, I'm fairly active here.

Btw, do you know any C#?


Hi, sorry it took so long for me to resurface, I've been sorting stuff for the new uni house :)

Thanks dude, for the offer of a helping hand, I may well indeed pm you!

I'm going to be swimming in not-prepared-enoughness this year - kind of going off topic here, but I have a project this year to load a 3DS model, and I kind of have code working to load a .obj into generic structures, so some coming-together of my resources needs to happen here

I agree, it's a good foundation - but I'm only young, and a poor student: I need more books in my life! I've ordered Beginning Game Programming with DX11, and Practical Rendering and Computation with Direct3D 11, I've also got Data Structures and Algorithms by Adam Drozdek from the library and I plan to keep it as long as possible. I'm not worried about OpenGL right now, just keeping as many structures as API independant as possible.

Any other kind of drilling in the inheritance/abstraction and a decent definition or two (remind me, what's an interface? I keep thinking of it as your public methods..?) to remind me of how things should fit together would be good though. The thing is Point and then Shape : public Point don't make sense as absract classes until you've got 200 lines of model class lol

I had a read through the conversation on my phone of all devices, that's gonna be brill to dip in and out of while I'm reading other things, thank you :)

PS: Indeedy, a bit of .NET from college, and XNA from getting bored in college - I'm a veteran of converting Riemers XNA3 to XNA 4 :P

Catching Up: so a renderer should be passed a mesh (which has it's own shader objects/materials) which it renders..

#include "mesh.h"

class Renderer {
bool Create();
void Render(mesh){
//?
}
void Destroy();
};

a question thats been on my mind - all these DX objects that have a Release() method - can I put them on a heap? - I'm assuming the same can be done with meshes?

How would you represent the shader parameters though as they are likely to be different for each shader and the render() code shouldn't really have to know what paramaters exist and are required to be set for each different type of shader should it?

I'm currently using a 'UniformGroup' abstraction, which maps to uniform buffers in OpenGL 3+, constant buffers for D3D11, and sequences of uniform calls for older APIs.

I don't quite have the mapping between those three underlying forms down yet, but it seems a promising approach.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

This topic is closed to new replies.

Advertisement