Stuck at design: Viewports and graphics

Also I've always wondered what is really more efficient, rendering the viewports onto a texture and storing it, to later render those textures in the proper order and disposition, or to just change viewports and render directly in each to screen which is what I'm currently doing...

I will say that viewports are faster because you don’t have to do the last merging process and also consume less memory because you don’t need these two extra render targets.

And for your main question: I read it all two times and still don’t get it.

“how to determine from content (not hardcoded in code, butrather on the data asset loaded along with textures and models that represent agiven object)”

How do you associate shaders with models? Do you store any xml data about the game objects? I really don't get your problem.

How do you associate shaders with models? Do you store any xml data about the game objects? I really don't get your problem.

Well pretty much yes, If you've seen the RPG sample I used something similar, on top of the actual model, texture and so on, any additional data needed to combine all that stuff and make for instance a pac man (without any behavior) is provided through a data structure loaded as content, kind of like a config file, basically I tried to completely separate Behavior and State from Data. The data structure is loaded from XML files added to the XNA content pipeline which then get compiled into binaries.


The thing is, as effects get more specific they start to require specific additional data to be created, easiest example would be the normal mapping effect, which needs the normal map texture, this texture would be referenced in the graphic data structure of the object that uses it, but when adding that into the graphics system, how do I know which batch it should go into to put that data to use?
It may be important to state that objects do not render themselves, the batches do this for them along with applying the graphic settings they need.
However as far as available data goes, an object with data for normal mapping rendering might just as easily be rendered with a normal shader, since it requires only a subgroup of the data used for normal mapping.


I can hard code most of this things in the game implementation but I'm trying to create this as if it were to be used by someone else, I'm trying to find a comfortable way to define this preferences from content and not code.

Think of it as a user, in a framework that allows you to use multiple different shaders to render an object, how would you like to choose which one?
Also right now you have to explicitly declare which batches are associated to each viewport, I want to find a way to automate that, so the user doesn't have to do it.

Hi NEXUSKill!! Now I understand you better. I think.

The idea of a batch is to change the less possible the GPU execution data, and you want that. Also, you have for every shader/material (I don’t know if you have only blinn-phong or more materials) several techniques. For instance: one technique uses a base color, another a base texture, another bump map with a base texture, and another parallax mapping, and so on. So, you want to know how to separate this in batches… good question.

I have to implement batches in my XNA engine but I think to batch first for materials (i.e. they have to have the same parameters) and then for techniques of the same type of material and then for type of material. All of this will be transparent to the user.

I don’t how this could be done in detail, but is really so hard to code this by hand? I just ask, don’t know yet, I have to do it first.

This helps you? Sorry if not.

Look at this an ignore the iphone thing: http://cw3f294.china...l-Batching.html

Think of it as a user, in a framework that allows you to use multiple different shaders to render an object, how would you like to choose which one?
Also right now you have to explicitly declare which batches are associated to each viewport, I want to find a way to automate that, so the user doesn't have to do it.

This was the only thing I understood. The reason being that you have strayed a bit off track and you are trying to explain your problem from that viewpoint.

Having strayed off course a bit, you need to back up.
Let’s take it one step at a time.

#1: In a framework that allows you to use multiple different shaders to render an object, how would you like to choose which one?
The shader is selected when it is time to render.
A shader manager can be erected to accept on input a set of flags that describes the features of the shader desired, and on output it provides a (hopefully shared) pointer to a shader that does that.
The easiest way to make shaders with various levels of features is to take advantage of preprocessing, using #ifdef.
Simply create a file that has an #ifdef for each feature you want to support, and when the shader manager needs to create a new shader, it maps the flags passed to it to a set of macros, and thus you have a new permutation of the shader.
In this way you only need to make one file (basically) and it can automatically be built into different versions, some features remaining and some lacking.

So even if the same object needs to be rendered a second time with a different shader, this is no problem because it receives a shader pointer on every render. Of course you can make this faster by checking if the flags have changed and if not, use the same shader as last time, etc.

#2: Also right now you have to explicitly declare which batches are associated to each viewport, I want to find a way to automate that, so the user doesn't have to do it.
This is where I consider you have strayed off course. You need to restructure this area heavily.
Firstly, a batch has no meaning in such a high-level context. A batch is a set of rendering commands that require no change in rendering states to be completed.
Normally batching is not a preprocessed procedure. You can’t define it by hand.
A render queue is used to accept model render data as input in any order, and it creates an order from that data that basically allows batching. The order of renders that requires the fewest changes to the rendering device.
But this is strictly dynamic. Don’t even think for a second that you can make a batch by-hand. It may change every frame, and you will always need to re-batch, or re-sort, every frame.

A “batch” so far has nothing to do with viewports. You have mixed terminology.
Your next goal is to put objects into viewports. That is, associate objects with viewports.
Well there are 2 ways to go about this, and you may even need to mix them.

#A: Allow multiple instances of your scene manager. Naturally, you do have a scene manager, right? If you expect to get any form of “automatic rendering” done than you will be using some kind of manager that knows about each object in the scene, so it can ask them to render themselves.
Well, you may very well need multiple of these. Basically, multiple scenes, each containing their own set of objects which are rendered completely independently of every other object.

#B: But that is not to say that using multiple scenes, one for each viewport, is the way to go. While you may need the ability to have multiple scenes at once, each scene should also have the ability to hold multiple camera slots at once. In this way the same scene can be rendered from multiple points of view. This is basically like a 2-player splitscreen that we see in consoles.
All of the objects are the same in both renders, so there is no reason to make 2 different scenes with duplicate objects each.
While again we accept that multiple scenes can still be made, we also add multiple cameras to each scene. You can enumerate them to make them clear.
This is my enumeration:


/**
* Sections of the screen. Useful for multiplayer rendering.
*/
enum LSE_SCREENS {
LSE_S_FULL_SCREEN, /**< A single render that takes the whole screen. */
LSE_S_2P_SCREEN_UP, /**< The top half of a 2-player render with the screen split horizontally. */
LSE_S_2P_SCREEN_DOWN, /**< The bottom half of a 2-player render with the screen split horizontally. */
LSE_S_2P_SCREEN_LEFT, /**< The left half of a 2-player render with the screen split vertically. */
LSE_S_2P_SCREEN_RIGHT, /**< The right half of a 2-player render with the screen split vertically. */
LSE_S_4P_UP_LEFT, /**< A quarter-screen render of a 4-way split screen in the upper-left part of the screen. */
LSE_S_4P_UP_RIGHT, /**< A quarter-screen render of a 4-way split screen in the upper-right part of the screen. */
LSE_S_4P_BOTTOM_LEFT, /**< A quarter-screen render of a 4-way split screen in the lower-left part of the screen. */
LSE_S_4P_BOTTOM_RIGHT, /**< A quarter-screen render of a 4-way split screen in the lower-right part of the screen. */

LSE_S_TOTAL /**< Total screen types. */

};

When you want to render using a given screen viewport, you just pass one of these values to the scene manager and it will set the viewport automatically.
Then you can make this fully automated by having the artist select which screen type he or she wants and having the engine translate that into these viewport enumerations on its own.


L. Spiro