C++ framework for 3.1?

[shadmar]

We could make one ourselves, which supported some of the features like in 2.5.

http://www.leadwerks.com/wiki/index.php?title=Framework

 

Would this be a bad idea? or why not? Just simple and lightweight.

[Rick]

I always felt one of the main benefits of the 2.x framework was not having to deal with multiple worlds. It had some other nice helpers in it like FOG, DOF but not having to mess around with handling multiple worlds ourselves was the winner for me. I seem to recall the main reason for multiple worlds was transparency issues that a deferred renderer caused. I thought that was all worked out with only 1 world now in 3.x though? 3.x seems so much more shader based that I wonder if a generic framework would work as it would most likely rely on shaders existing already in the project where I can't recall if 2.x needing those external shader's to exist for SSAI, GodRays, HDR, Bloom etc.

[shadmar]

Stuff like refraction and reflection are very heavy to render using just one world since you basicly re-render the same stuff twice only hide the refracted or reflected stuff. Using worlds I think would make this alot faster. (haven't really tested) that much.

 

However I can supply shaders to go with the framework, but I'm not all that senior CPP, I'd like someone else to set up the base class(es).

Github or a bitbucket project on this could be nice and people can just work / submit stuff / patch stuff when they have time or it's needed.

 

This can be done in lua probably aswell. But I just wanted some opinions.

[Rick]

I think it's a good idea as long as it allows for custom shaders to be used. I think the original basically only allowed 1 shader file for each effect (probably hardcoded in the framework). I think testing with multiple worlds to see if it's a lot faster would be needed first though as that remains one of the biggest benefits of the framework and if it's not required it would diminish the purpose of it some.

 

Lua might be a little more awkward I think as it's main attraction is using the editor to do a lot of stuff vs the person coding things like the creation of worlds and cameras vs using the camera entity in the editor and attaching shaders via the editor. If multiple worlds makes things so much faster then perhaps the editor should have some things altered to help with that without coding.

[AggrorJorn]

I think a RenderFramework written in C++ (which can also be called by Lua) could be nice especially if it is opensource maintained via bitbucket or github.

 

So basically we would have this

Init()
{
 fw = new Framework();
 fw->SetGodRays(true);
 fw->DistanceFog(true, ColorVec4, floatDistance);
 fw->SetBloom(true);
 fw->SetSSAO(true);
}
Update()
{
 //game code
 fw->Update();
 fw->Render();

 //GUI stuff
 vsync(true)
}

[AggrorJorn]

What would be an ideal way of offering the framework? It could be just the source or compiled libs / dlls.

[Rick]

I think we need more customization allowed. For instance what shader does SetBloom() use? I think a default bloom shader file is nice, but maybe have an optional param that let's us pick the shader file to use as others may have new bloom shaders they want to use instead of a default one. All effects could be like that.

 

I vote source since it'll always work on all compilers and we wouldn't have to maintain libs. We have to think about mac/linux so source handles that also.

[AggrorJorn]

Also the name 'framework' is really generic. If it is restricted to rendering I would suggest calling it the EffectsFramework or RenderingFramework (or anything in that trend.). If someone would be making an FPS framework we would have similar naming styles.

[shadmar]

We might also throw in a waterplane wich does reflections aswell, but it would require clipping shaders on everything else, but maybe for later.

 

I think we should overload everything so we can adjust them as wanted something like;

 

fw->SetBloom();
fw->SetBloom(Shader* shader, float low, float middle, float cutoff, float strength);

[Rick]

A design to think about with having these SetXXX(). A more flexible approach seems like having an Effect class and an fw->AddEffect(Effect*) function. That way people can just add new effect classes without directly effecting the main framework class.

[shadmar]

Nice, that why I would need you guys.!

[AggrorJorn]

Is this how it could look?: In the Source folder of all projects you place the RenderFramework folder. This folder contains all classes. how about the shaders? Do they need to be part of the shader folder to work?

[shadmar]

Do they need to be part of the shader folder to work?

No, they could be anywhere.

[Rick]

Is this how it could look?: In the Source folder of all projects you place the RenderFramework folder. This folder contains all classes. how about the shaders? Do they need to be part of the shader folder to work?

 

I like the RenderFramework folder idea. The default shaders would need to be in a certain spot to use an overload that doesn't specifically load a shader.

 

 

So maybe something like:

 

 

class IEffect
{
public:
virtual void Update();
virtual void Render();
};

 

 

class Bloom : public IEffect
{
public:
Bloom();
Bloom(string shaderFilePath, float low, flow middle, float cutoff, float strength);
};

 

 

RenderFramework render;

render.AddEffect(new Bloom());

render.Update();
render.Render();

[AggrorJorn]

Then I would suggest adding a subfolder to the RenderFramework folder that contains all the shaders (and their possible sub folders).

[Rick]

I think what we have to think about is what is an effect. It's basically a shader with settings that need to be set in the shader from the program.

 

Person A can make a bloom shader that has x variables that need to get to the his shader, and person B can make a different bloom shader that needs different variables. So an Effect class basically combines a specific shader to specific parameters to get to that shader. So this would mean a person would have to make their own class name for their effects or use namespaces. So either:

 

fw.AddEffect(new ShadmarBloom());

 

or

 

fw.AddEffect(new Shadmar::Bloom());

 

Going this route I don't think one would have to pass a shader in as it would be hardcoded in that persons class. We would just pass other parameters that get passed onto the shader to control it's look/feel.

 

 

If we go the route of passing in a shader, then it gets so much more generic because it could be any shader along with any pieces of data to pass to that shader. If this was javascript it would look like:

 

fw.AddEffect(Shader::Load("bloom"), { low = 5, middle = 2, cutoff = 1, strength = 6});

 

Translating something like that to C++ is a little more difficult as there is no type information and I think we'd need that to send the parameters to the shader, but you see how an effect seems to simply be a shader and parameters for that shader.

 

I like the namespace method as it's probably the "proper" way to do things, but I know some people don't like namespaces.

[shadmar]

I think it should be very easy to use. Oneliners are easy to use, if we need multiple lines per effect, it's more trouble than it's worth.

I mean if it's open source, you can just adapt it yourself for a custom shader?

[Rick]

All the styles I listed above are 1 liners for usage though

 

I personally like:

 

fw.AddEffect(new Shadmar::Bloom(15, 2, 5));

 

Is that flexible enough? As a content creator that means you make a class class Bloom that derives from some kind of IEffect class inside a namespace you called Shadmar (in case someone else makes a Bloom class this is how we tell them apart). Your Bloom class would hardcode where the shader is located.

 

 

I mean if it's open source, you can just adapt it yourself for a custom shader?

 

Being able to modify it for my own usage is one benefit but also being able to add to it for others to use is (the biggest benefit IMO) another and that means making sure what a person adds doesn't collide with what another person adds.

[AggrorJorn]

What is the advantage of storing the shader effects in a namespace? Just for clearity or does it have a deeper purpose?

[Rick]

What is the advantage of storing the shader effects in a namespace? Just for clearity or does it have a deeper purpose?

 

My thought is because with it being open source we would want others to contribute at any point in time their effects, which might be different takes on existing effects. Right now we basically just have Shadmar doing these, but tomorrow we could have another person who comes along and says they have a different take on the Bloom effect so they make their own Bloom shader that requires different parameters than Shadmars. So now we have 2 takes on a Bloom effect that take different parameters created by 2 different people. Maybe at some point in our games we want to use both. How to account for that? Namespaces would be the proper way in C++.

 

The question becomes is this an open framework that allows people to add to it for everyone to use and if so how to allow this without colliding with existing effects, which would make more work for the user as they piece together the code and if there is a collision with effect name or whatever they have to work out themselves.

 

That's my line of thinking anyway. I don't think adding a namespace would cause that much more work for both the creator or the user. These effects classes are pretty basic I'm thinking as they pretty much transport parameters to the shader and so some camera/world switching.

[AggrorJorn]

Okay sounds good.

 

And since this is going to be very popular we can even set up our own template for the project manager.

[Rick]

So maybe something similar to the below? Thoughts/ideas/concerns?

 

// part of the framework
class IEffect
{
protected:
  // protected so our derived classes can use them
  // these get filled in from the framework
  World* bgWorld;
  World* fgWorld;
  Buffer* bgBuffer;
  Buffer* fgBuffer;
public:
  virtual void Update()=0;
  virtual void Render()=0;

  void SetBGWorld(World* world) { bgWorld = world; }
  // etc. for worlds and buffers
};

// my take on the Bloom effect
namespace Rick
{
  class Bloom : public IEffect
  {
     public:
     Bloom()
     {
     }

     virtual void Update()
     {
     }

     virtual void Render()
     {
     }
  }
};


namespace Shadmar
{
  class Bloom : public IEffect
  {
  public:
     Bloom()
     {
     }

     virtual void Update()
     {
     }

     virtual void Render()
     {
     }
  };
};


class RenderFramework
{
private:
  World* bgWorld;
  World* fgWorld;
  Buffer* bgBuffer;
  Buffer* fgBuffer;

  list<IEffect*> effects;
public:
  void RenderFramework()
  {
     // create the worlds and buffers
  }

  void AddEffect(Effect* effect)
  {
     effect->SetBGWorld(bgWorld);
     // etc. set the effects worlds/buffers

     // add this effect
     effects.push_back(effect);
  }

  void Update()
  {
     // loop over effects and call Update()
  }

  void Render()
  {
     // loop over effects and call Render()
  }
};


// usage
RenderFramework fw;

fw.AddEffect(new Shadmar::Bloom());

fw.Update();
fw.Render();

[shadmar]

Some effects needs to be in certain order to look correct, are we going to let the user decide which order is correct or should we default render them in correct order? (it would look strange if you don't get it the correc wayt)

[Rick]

Some effects needs to be in certain order to look correct, are we going to let the user decide which order is correct or should we default render them in correct order? (it would look strange if you don't get it the correc wayt)

 

That's a good question. I'd be more inclined to leave that up to the user because it might allow them to make funky looking effects for whatever they want it to be used for. Maybe they want it to not look right for some strange alien effect

 

It gives the user more freedom and I'm all for that. Even if that freedom seems strange Also, we don't know of every single effect that will ever exist so it's easier to let users have that control than to have to update the framework when totally new effects come out and have to be ordered a certain way.

 

The only thing I didn't cover in my example is removing effects. We'd have to have a way to remove a given effect. Maybe AddEffect() returns the IEffect object and we can use that to remove and alter the effect later during run-time. Could probably have a ClearAllEffects() also.

[AggrorJorn]

I like this approach. I do have the concern about rendering the effects in a needed order. Although I like the freedom of everyone adding the effects in the order they want, we could provide a solution to some of the core features.

 

Something like an effect-collection is what I would have in mind.

 

An effect-collection can have effects added to it in a specific order and than the effect-collection can be added to the renderframework.

 

ec = new EffectCollection(name "superproces")
ec->AddEffect(EffectA);
ec->AddEffect(EffectB);
ec->AddEffect(EffectC);
framework->AddEffectCollection(ec);