Jump to content

  • Log In with Google      Sign In   
  • Create Account

We're offering banner ads on our site from just $5!

1. Details HERE. 2. GDNet+ Subscriptions HERE. 3. Ad upload HERE.


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


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
32 replies to this topic

#21 CC Ricers   Members   -  Reputation: 651

Like
0Likes
Like

Posted 19 September 2012 - 09:30 AM

Swiftcoder's example is almost exactly how I started out with my first graphics engine. Only I wasn't using interfaces for rendering, since the engine was targeted only for DirectX 9.

Some other challenges you may plan for in the future: After you get your basic renderer working, figure out how to cull objects. Maybe sort your objects in different containers and pool for the ones you need to render.
My development blog: Electronic Meteor

Sponsor:

#22 ATC   Members   -  Reputation: 551

Like
0Likes
Like

Posted 19 September 2012 - 09:42 AM

Some other challenges you may plan for in the future: After you get your basic renderer working, figure out how to cull objects. Maybe sort your objects in different containers and pool for the ones you need to render.


I'd also suggest culling in a "chain", of sorts:

Scene Node >> Object >> Model >> Mesh

For instance, a large model made up of many individual meshes or an "object" made up of several models might only be partially on camera. You would not want to cull that entire object/model, nor would you want to draw the entire thing and waste "GPU juice" (lol). So you test in sequence... first make sure the scene node is visible at all, then checks its object groups, then the models of each object group and the meshes of each model.

If your game is very small and simple then this broad testing can be a bottleneck. But in large game worlds populated with tons of geometry it can indeed save a lot of time; especially when individual models and their meshes are required to use multiple textures with complex shaders and dynamic lighting parameters.
_______________________________________________________________________________
CEO & Lead Developer at ATCWARE™
"Project X-1"; a 100% managed, platform-agnostic game & simulation engine


Please visit our new forums and help us test them and break the ice!
___________________________________________________________________________________

#23 lucky6969b   Members   -  Reputation: 624

Like
0Likes
Like

Posted 19 September 2012 - 11:05 PM

ATC, you're specially kind. I'd dig into it after I finish the framework.
Thanks
Jack

#24 mynameisnafe   Members   -  Reputation: 252

Like
0Likes
Like

Posted 21 September 2012 - 02:40 PM

Can you point me to that conversation you had with swiftcoder perhaps please?

I've done about half the DX11 rastertek tutes, and I'd like to start building something more sensible, and what you've suggested here makes a lot of sense.

I've got a vague idea of what I want, but I've only three years C++ / UML. I've bought two books from Amazon about C++/DX11, they look like the most recommended but they haven't been delivered yet. That conversation would make beautiful reading!

#25 lucky6969b   Members   -  Reputation: 624

Like
0Likes
Like

Posted 23 September 2012 - 11:58 PM


Is this you guys talking about?
http://dundee.cs.que...me_Architecture

A word to the wise: your life doesn't have to be ruled by UML diagrams and class hierarchies. Formal design process has a place, but it's generally not necessary to be so formal.

A lot of the beauty of data-driven design is in how it simplifies designs:
struct Mesh
{
	 VertexBuffer *vertices;
	 IndexBuffer *indices;
};

struct Camera
{
	 Matrix4 viewMatrix;
	 Matrix4 projectionMatrix;
};

class IMeshAnimator
{
	 IMeshAnimator(const Mesh &mesh);
	 virtual void update(float deltaTime) = 0;
};

class IRenderer // Has OpenGLRenderer and D3DRenderer as subclasses
{
	 virtual void render(const Mesh &mesh, Matrix4 modelMatrix, const Camera &camera) = 0;
};

Take a look at how conceptually clean this is:
- The Mesh and Camera classes are just pure data containers.
- The MeshAnimator uses composition, instead of inheritance.
- The Renderer just deals with individual render operations.


I can't understand this, if the Renderer is responsible for updating its children, I expect to use a pointer like this
class IRenderer
{
  virtual void render(const Mesh &mesh, Matrix4 modelMatrix, const Camera &camera) = 0;
};

class CD3DRenderer : public IRenderer
{
	 void render(const Mesh &mesh,....);
	 bool UpdateFrame (Mesh *mesh, Matrix4 world);
};

bool CD3DRenderer::UpdateFrame(Mesh *mesh, Matrix4 world)
{

	   UpdateAllChildren((D3DXFRAME_DERIVED*)m_mesh.m_Root, world);
}

void CD3DRenderer::UpdateAllChildren(D3DXFRAME_DERIVED* pFrame, D3DXMATRIX* pMat)
{
	   if (pFrame == NULL) return;

	   D3DXMatrixMultiply(&pFrame->CombinedTransformationMatrix,
	         &pFrame->TransformationMatrix,
      	   pMat);
	  if(pFrame->pFrameSibling)UpdateAllChildren((D3DXFRAME_DERIVED*)pFrame->pFrameSibling, pMat);
	  if(pFrame->pFrameFirstChild)UpdateAllChildren((D3DXFRAME_DERIVED*)pFrame->pFrameFirstChild, &pFrame->CombinedTransformationMatrix);
}

The problem is when I pass in the mesh as const&, the mesh cannot be modified, I have integrated the knowledge of swiftcoder and Aressera.
Thanks
Jack

Edited by lucky6969b, 24 September 2012 - 12:00 AM.


#26 swiftcoder   Senior Moderators   -  Reputation: 10242

Like
0Likes
Like

Posted 24 September 2012 - 07:52 AM

I can't understand this, if the Renderer is responsible for updating its children, I expect to use a pointer like this

The Renderer is never responsible for updating anything. The purpose of the Renderer is to render. [see: separation of concerns]

Something else needs to be responsible for triggering updates. I have a set of services called 'RenderTime', 'WorldTime', 'ClockTime', to which entities can subscribe - anything subscribed to RenderTime will be updated each frame, anything subscribed to WorldTime will be updated each in-game 'tick', and so forth.

Tristam MacDonald - Software Engineer @Amazon - [swiftcoding]


#27 ATC   Members   -  Reputation: 551

Like
0Likes
Like

Posted 24 September 2012 - 12:15 PM

Can you point me to that conversation you had with swiftcoder perhaps please?


You can find the better part of our conversation here.

I've done about half the DX11 rastertek tutes, and I'd like to start building something more sensible, and what you've suggested here makes a lot of sense.

I've got a vague idea of what I want, but I've only three years C++ / UML. I've bought two books from Amazon about C++/DX11, they look like the most recommended but they haven't been delivered yet. That conversation would make beautiful reading!


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#?
_______________________________________________________________________________
CEO & Lead Developer at ATCWARE™
"Project X-1"; a 100% managed, platform-agnostic game & simulation engine


Please visit our new forums and help us test them and break the ice!
___________________________________________________________________________________

#28 lucky6969b   Members   -  Reputation: 624

Like
0Likes
Like

Posted 24 September 2012 - 11:37 PM


I can't understand this, if the Renderer is responsible for updating its children, I expect to use a pointer like this

The Renderer is never responsible for updating anything. The purpose of the Renderer is to render. [see: separation of concerns]

Something else needs to be responsible for triggering updates. I have a set of services called 'RenderTime', 'WorldTime', 'ClockTime', to which entities can subscribe - anything subscribed to RenderTime will be updated each frame, anything subscribed to WorldTime will be updated each in-game 'tick', and so forth.


Should 'RenderTime' be encapsulated into another class, in other words?
Thanks
Jack

#29 ATC   Members   -  Reputation: 551

Like
0Likes
Like

Posted 25 September 2012 - 10:49 AM

Should 'RenderTime' be encapsulated into another class, in other words?


Not necessarily, if something needs to know when rendering begins/completes for example. You just don't want the renderer dispatching updates to your game logic or anything else. And you need to design things to enforce that. I would just use an event interface and implement events like "RenderBegin" and "RenderEnd" if you have a class like "GraphicsManager" that needs to know when these things happen. Just completely separate this from the line of updates dispatched to your engine/game logic. The Renderers job isn't to update entities and doesn't usually need to "tell" them anything, but just draw them.
_______________________________________________________________________________
CEO & Lead Developer at ATCWARE™
"Project X-1"; a 100% managed, platform-agnostic game & simulation engine


Please visit our new forums and help us test them and break the ice!
___________________________________________________________________________________

#30 lucky6969b   Members   -  Reputation: 624

Like
0Likes
Like

Posted 27 September 2012 - 02:54 AM

In general speaking, events and states can be implemented using interfaces or classes?

I am quite familiar with event interface, could you please give me an example?

If an event interface ain't a class, what will it be like?

Thanks
Jack

Edited by lucky6969b, 27 September 2012 - 09:37 PM.


#31 jbb   Members   -  Reputation: 328

Like
0Likes
Like

Posted 28 September 2012 - 08:11 AM

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.

#32 mynameisnafe   Members   -  Reputation: 252

Like
0Likes
Like

Posted 29 September 2012 - 11:05 AM

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?

#33 swiftcoder   Senior Moderators   -  Reputation: 10242

Like
0Likes
Like

Posted 29 September 2012 - 02:59 PM

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 - Software Engineer @Amazon - [swiftcoding]





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.



PARTNERS