This project is read-only.

question about enum VIEWTYPE

Jan 20, 2015 at 10:27 PM
when I work with multiple pass shaders, I usually take advantages of those enum values already defined in VIEWTYPE, i.e., VT_PERSPECTIVE, VT_FINALPASS. I assume that the order of these values determines the execution order for the shaders (i.e., shader for VT_PERSPECTIVE will be executed before VT_FINALPASS).

Suppose I want to do something render tasks different from all the view types currently defined (e.g., I want to do some image processing between VT_PERSPECTIVE and VT_FINALPASS), can I just add my own view type into VIEWTYPE ? what's the recommanded way to do it?
Jan 24, 2015 at 1:05 PM
This mechanism was added to the engine a long time before I decided to open source it, which was when I was the only developer. Unfortunately there isn't a way to easily add a new type, and I'll describe why.

The enumeration is used to identify the type of the view. In addition, it is used to declare an array of render effects within a material by using the size of the enum. The individual items within the enum are used both during material construction (assigning shaders and state objects), and then again when doing the rendering (consuming the shaders and state objects). Since the array is a plain old fixed size array, there isn't currently a mechanism to grow it at runtime.

With the current setup, you could do one of two things to work around this. First, since there is about 10-15 predefined viewtypes already there, you can just reuse a couple of them under a different name by assigning your new viewtype name to one of the existing values. The other option is to just modify the enum to include the elements that you want to add.

However, this is an area that should be updated - you are 100% correct that this is not quite the right way to do this. Since they are fixed size arrays, that means when nobody is using multiple views that there is just extra memory being used without any benefit. So it would be nice to have something that could be variable size, but it still has to be very fast to access the data. What do you think would be a good solution? It could be changed to something like a std::map and the key can be just an integer that people define during initialization. I would be open to hear other options if you can think of any!
Jan 29, 2015 at 3:42 PM
Thanks for the explanation. Using a map sounds good. Sorry that I'm not familiar with the underlying structure of how VIEWTYPE is consumed in other part of the program, and I cannot offer much more than that.

Finally a related question, does the order of VIEWTYPE determines the execution order of the shaders? Or the Task::QueuePreTasks() defines the shaders need to be executed before the current shader? I noticed that the order of calling QueuePreTasks() is not arbitrary. For example, assume I have 3 pass pixel shaders to be executed,
Three Task subclasses are created with their view type defined as VT_PERSPECTIVE (1st pass), VT_GBUFFER(2nd pass) and VT_FINALPASS(3rd pass).
The render task of the final pass creates resources for the first and the second pass. And in its QueuePreTasks(), it must queue 2nd pass render task first, then the 1st render task. Otherwise, the result is wrong. I'm wondering what if I define 1st pass as VT_BGUFFER and 2nd pass as VT_PERSPECTIVE, is it going to break anything?
Jan 30, 2015 at 3:06 AM
The actual order of the entries in the enum don't matter for the execution order. You are correct about the QueuePreTasks call, and this is intentional to let any particular view to 'queue' any other views that must be executed prior to itself. The view's should be process in the order that they are queued if you are running in single threaded mode, and they will be processed in parallel if they are in multithreaded mode.