Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!

1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


Member Since 08 May 2012
Offline Last Active Today, 12:51 PM

Posts I've Made

In Topic: "Game Physics Engine Development" - resting contacts

Yesterday, 11:24 AM

Hi Irlan,


If I remember correctly, Ian sorted contacts according to "seperating velocity" which is defined as


float sep_vel=((Bvel-Avel)dot(normal) or put another way


float sep_vel=(relative velocity)dot(normal)


The idea being that the contact with the smallest (ie most negative velocity) should get sorted first


After I implemented this function however, and iterated over Ian's suggestion of at least 2x through the contact resolver, I noticed no discernable difference.

Of course, I speak as someone with very limited knowledge.




Something like that. Anyway... that book it is outdated and for  learning purposes we should use all the GDC slides that was made by authors of current most used engines because they talk a lot about approaches that can reduce CPU overhead while satisfying solving constraints (sequential impulse solvers are quite stable).

In Topic: Clip plane parallel to the screen

Yesterday, 09:38 AM

The look vector isn't a plane without the camera near plane distance. 


The near plane value of your camera is the signed distance from the origin to the plane and that are the variables for a plane equation.


Make sure the camera look vector it is normalized.

In Topic: Propagating data through an engine to constant buffers

Yesterday, 08:15 AM

Are you saying instead that the Terrain class itself should just directly own the necessary buffers and subset table?  This isn't a huge refactoring effort by any means to pull out of the model class and give to the terrain directly, it just seems like it's duplicating code.


A terrain should not be rendered in the same way of a model. A terrain also does not has sub-sets; it contains what a terrain needs to have: vertex buffers, index buffers, textures, etc.—specific functionality. 


For more that the terrain graphics data looks like the model data (buffers and resources) you don't need to explicity let a terrain be dependent of a model.


Further, you may want to do specific things with a terrain such terrain rendering, etc. Remove any dependency that you're having with the model and the terrain and you'll be doing in the correct way. This is not duplicated code (since the objects characteristics are totally unrelated and well defined).


Don't be afraid of expanding 10 classes to 100 when it make sense.


Later, you will see that complexity depends of the pre-defined requisites, and in your case the requisites are: terrain, models, and your entity-component system, and you should separate that until no dependency is noticed.


A terrain knows how to render itself, so you can cut-off your TerrainRenderer for a while.


A model knows how to render itself, so you can cut-off your ModelRenderer for a while.


Your "Render System" it is a scene. Yet you said that on the comments but since you're limited to call everything a "system" you're limited also to create objects that can be managed by that system you didn't change the class name and its characteristics tongue.png . 


A scene knows what it contains, so you can cut-off the RenderSystem for a while.


The final result would be something like that (other objects such entites, actors are removed from the example for simplicity purposes):

class CScene {
protected :
     CVector<CRenderableModel*> m_vRenderableModels;
     CTerrainManager m_tmTerrainManager; //It has a lot of terrains, and terrains has specific functionalities of terrains.

Simple as that!


Now you know that you can call CRenderableModel.Render() and CTerrain.Render(), etc. in the game-engine side at any time you want. Just make sure you've loaded the resource first laugh.png .

In Topic: Propagating data through an engine to constant buffers

Yesterday, 04:58 AM

Also, thank you for your comments.  I think you and I are actually on the same page in a lot of places, and maybe something like the shader manager is the missing piece for me.


Just remember of the SRP (Single Responsability Principle): if you're doing something that is unrelated to a class you need to create another class and give that this responsibility. So, dividing tasks it can be a great start.


But it also necessarily contains a model as described above (with a mesh containing a vertex and index buffer), and that model can be added to an entity as its render component so it will get drawn in the same rendering loop as every other entity.


The more abstracted you do things that don't necessarely need to be, more you tend to write unmaintainable code. A terrain is so specialized that you find books out there like "how to render terrains", "shader guide for terrains", "pratical rendering with terrains", etc. A terrain doesn't have a mesh. It has buffers, a lot of texture layers (to do texture blending, etc.); do not mess up with the models.


Correct!  Render components own a pointer to a model instance, that's all.


Looks like your "render component" is a model instance. If it is then it isn't a problem, but a render component can be anything that can be rendered at the game-side.


If you're not confortable with the entity-component-system I'd recommend creating a simple hierarchy such game entities (used in CryEngine, ID Tech, etc.) and keep sub-dividing the entities responsibility so do the components. I don't use ECS myself because I think that for one single person to manage that in a engine it's asking for unmaintainable code.

In Topic: Propagating data through an engine to constant buffers

29 January 2015 - 05:47 PM

The main problem you're having is abstracting everything using the component model; it is creating a conflict of what things you should pass to the shader manager in order to set the correct data.


Models are not render components.


A model (at run-time) is a renderable model, and you need to create a specialized library in order to know what things you should pass to the shader—this is the only way of don't mix up game engine high-level architeture with low-level architeture (models are lower level than a render component).


A model library knows what a graphics library is. Thus (the game simulation), a model that can be rendered is just a bunch of buffers and shaders information such textures, a local-matrix, and it has no loading information (once they're loaded you can't change what you're rendering because isn't a animation).


The graphics library (it supplies slots to bind a matrix, a option to set the current view-matrix, projection-matrix, shadow-map matrix, etc.) is what a model and a terrain need to be rendered (they play together).


Terrains aren't models.


A terrain library knows what the graphics library is. A scene doesn't have terrains (a terrain isn't a actor nor a camera nor a light), so you need to re-iterate when you say that a render component can have a pointer to the terrain. 


After separating a models and terrains you need a way to pass the information to the shader. That's when you see what things you can reduce in order to not keep the graphics library dependent of any other module.


There is no 100% default shader data. 


Beginners graphics programmers trying to abstract 100% a shader is the same thing of physics programmers trying to abstract constraints, and they're only asking for pain (at least at the beginning). 


Need some vegetation effects in the game? Create vegetations effects in your shader and make sure that you have a way of your shader manager (at software level) supply that to the class that manages vegetations that above the graphics module—this is just saying "create a simple slot in the shader and a function that passes the data (time, wind characteristics, etc.) to the shader at run-time".


A entity-component system it is at the highest level possible of a engine (if you define a engine being the module that uses everything on low-level modules). 


That said, you should be able to create some kind of shader parser in order to give the artists the ability to have a high-level view of your rendering architeture (fog, vegetation parameters, lighting models, shadow parameters, etc.). If you're not using any shader parser you can at least re-define what models, terraints, and game render components are before using them.


IMHO that's one flaw of a entity-component architeture because you keep stuck on "I can't do that, I need a abstraction layer", etc. instead of defining only one thing:


"Use componentization over inheritance, and make sure that you keep everything inside the engine module (the highest-level module on the game engine)".