Jump to content

  • Log In with Google      Sign In   
  • Create Account


Stuck at design: Viewports and graphics


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

#1 NEXUSKill   Members   -  Reputation: 453

Like
0Likes
Like

Posted 03 August 2011 - 08:04 AM

I post this here because it might be a little advanced for any of the current weeks but the DirectX / XNA forum has twice ignored this concern completely.

This is a dilema I have been fighting against for a few months now, after many times of writing shader drawing loops, creating hand picked associations between my graphic objects and the shader that renders them, and trying to push that into a multi viewport framework (of my own), I am officially stuck.

Here is my structure, my graphics system has a list of viewports, at least one that represents the full game window and acts as default.
first remark is that two viewports may be viewing the same world or not, in a split screen for instance, they both see the same world, but when used to render the contents of an interface window, its not the same world as other viewports would be seeing.
Within these viewports there may be many different graphic settings in place for objects that are rendered by different shaders, so I decided to batch graphic objects together by certain critical aspects of their render states to minimize graphic card settings modification, so I created Batches, which handle the shader and the settings for any graphic object associated to them and then draw them all in one batch.

For an object to be visible in a viewport, the batch in charge of its rendering is associated to that viewport, this creates a very powerful structure but its hard to initialize.
Nevermind space partitioning and potentially visible sets, I already solved that issue.

My issue is, how to determine from content (not hardcoded in code, but rather on the data asset loaded along with textures and models that represent a given object) which batch and view should a just loaded graphic object be assigned to.
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...

Any ideas?


Game making is godlike

LinkedIn profile: http://ar.linkedin.com/pub/andres-ricardo-chamarra/2a/28a/272



Sponsor:

#2 jischneider   Members   -  Reputation: 252

Like
0Likes
Like

Posted 04 August 2011 - 07:43 PM

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.

Project page: < XNA FINAL Engine >


#3 NEXUSKill   Members   -  Reputation: 453

Like
0Likes
Like

Posted 05 August 2011 - 09:57 AM

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.



Game making is godlike

LinkedIn profile: http://ar.linkedin.com/pub/andres-ricardo-chamarra/2a/28a/272



#4 jischneider   Members   -  Reputation: 252

Like
0Likes
Like

Posted 05 August 2011 - 09:31 PM

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

Project page: < XNA FINAL Engine >


#5 L. Spiro   Crossbones+   -  Reputation: 13010

Like
0Likes
Like

Posted 24 October 2011 - 09:24 AM

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
It is amazing how often people try to be unique, and yet they are always trying to make others be like them. - L. Spiro 2011
I spent most of my life learning the courage it takes to go out and get what I want. Now that I have it, I am not sure exactly what it is that I want. - L. Spiro 2013
I went to my local Subway once to find some guy yelling at the staff. When someone finally came to take my order and asked, “May I help you?”, I replied, “Yeah, I’ll have one asshole to go.”
L. Spiro Engine: http://lspiroengine.com
L. Spiro Engine Forums: http://lspiroengine.com/forums




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