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.


Engines - What to keep fixed and what not to


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

#1 Migi0027 =A=   Crossbones+   -  Reputation: 1987

Like
1Likes
Like

Posted 12 August 2013 - 01:24 PM

Hi guys, happy.png

 

developers love to give the user the freedom they want, but sometimes, too much freedom is quite bad, as some things are just too complicated, or just not practical, or might mess stuff up if done wrong.

 

One example of this was where I had to decide whether to use fixed functions for normal mapping, or leave that to the user to do while editing their custom material. But normal mapping isn't just something that's done within a seconds (copy... paste... tongue.png ), so I decided to make it fixed, like: (And it's used so much, and if you mess it up, features like, ssao, lighting, just doesn't work!)

// Enable Normal Mapping
myMaterial->SetFlag(MAT_FLAG_NORMALS);

// Set the texture
myMaterial->SetNormalMap(myTexture);

So...

Is leaving the normal mapping to a fixed function the way to go, or not? What experiences do you have where you needed to decide whether making a feature fixed, or leave it to the user?

 

Thanks! wink.png

 

PS. I don't know if this is too specific, if so, please say!


Hi! Cuboid Zone
The Rule: Be polite, be professional, but have a plan to steal all their shaders!


Sponsor:

#2 GuardianX   Crossbones+   -  Reputation: 1528

Like
0Likes
Like

Posted 12 August 2013 - 02:23 PM

I would like to hear opinions on this subject as well. I personally think that it is completely up to you to decide. Some kind of "design" decision. But it is really hard to decide when you should really stop making things flexible.



#3 Jason Z   Crossbones+   -  Reputation: 5164

Like
4Likes
Like

Posted 12 August 2013 - 07:29 PM

My take on this is to make the system as flexible as possible, and then if there are 'norms' that you want to include in the engine then you just implement them for the user in the flexible system.  This serves multiple purposes - they provide functionality out of the box, they serve as examples for others to use, and they force you to use your own system to implement something that you could reasonably expect your users to be able to do.  Sometimes that experience can be eye opening, and it will help you improve the usability of your engine.

 

By maximizing flexibility, this also lets you update things over time without breaking your whole engine.  Encapsulate your rendering code into logical chunks that are easily interchanged and supported by the structure of your engine, and you will be much happier in the long run.  Especially if you are the sole maintainer of the project, this will really be useful if you work on the engine for a long time (like I have with Hieroglyph 3!).



#4 nfactorial   Members   -  Reputation: 731

Like
0Likes
Like

Posted 14 August 2013 - 04:21 AM

From the example you gave, I would say you don't need the SetFlag( MAT_FLAG_NORMALS ) call. The fact someone calls the SetNormalMap should be enough for the lower level API to realise they want normals which reduces it to a single call and reduces the chance of someone making a mistake.

 

I actually think this should all be completely hidden at the high level, so no code outside the core renderer has an API like that at all. But I guess that's not really the direction your engine has taken and requires tool support. Consider for example, the high level code states 'I have a mesh that I render' and the game engine gives it a mesh along with the material. Suddenly the high level code can now render anything the designer wants it to with no code change. Anyway, that's a long discussion and a bit of a tangent so I will leave it as perhaps thought for the future.

 

n!






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