🔒 Locked

On Render Views

Started by Jason Z Jan 14, 2007 at 9:54 AM 3 replies 2.4k views

Original Post

Jan 14, 2007 at 9:54 AM

I recently received a question on my render view system, and figured I would share it with everyone if it might help anyone out. Here it is:

Quote:
Hello Jason... First of all sorry for bothering you. If you think i should make a thread about this, then please say it. I'm trying to implement your RenderView system as you described it in this thread. Back then i thought that your approach was too generic but after working on my implementation i ended up doing things similar to what you described. So i thought i should give it a try to see what i come up with. I think i understand everything from your description, but i have a little question, if you don't mind answering. Quoting your definiton of the renderviews :
Quote:
The render views are built around the fact that you can set any input and output render targets for them to use, which enables you to link them together and chain multiple rendering algorithms together.
The question is what happens with the other required inputs. You mention only render targets. But if a render view needs the scene, it has to get it from somewhere. But this is easy, if you keep a scene manager type of thing in your engine. But what happens with camera's? Let me explain. The main render view needs the current camera in order to render the scene. A cubemap render view needs the object's transformation for correctly placing the 6 cameras. A shadowmap rv needs the light's position and direction. The question is : Does the render view interface have entry points for configuring these things, or you have to know which render view you are using (in order to cast it) and you are calling special case functions (like SetCamera(), SetLight(), SetTransformation()). In your last post of the previously mentioned thread, you said :
Quote:
The thing to keep in mind is that the overall system is not designed to be able to add a new effect, drop it anywhere and the system will handle it for you. Instead, it is generalized so that any algorithm can be implemented - but the programmer still has to make sure everything will work together.
What i'm trying to accomplish is a data-driven framework for configuring render-views. E.g. if i want a reflective object to use a dynamic cubemap, i should be able to specify this at the material level. This way i don't have to bother creating renderviews by hand after the object is loaded, and i can create new renderviews, without the need to inform the engine about it. Is this possible with your design? Thanks for reading this, and hope you find some time answering. HellRaiZer

Hi HellRaiZer, I don't mind helping out - I didn't just wake up one day and understand what I was doing, lots of people have helped me out too!!! For question #1,

Quote:
The question is : Does the render view interface have entry points for configuring these things, or you have to know which render view you are using (in order to cast it) and you are calling special case functions (like SetCamera(), SetLight(), SetTransformation()).

I generalize the parameters into the shaders with three major categories: 1. Object parameters 2. View parameters 3. App parameters When I author a shader, I use the *.fx system in DX9. This allows you to specify semantics for each parameter, and I have defined the following allowed semantics: ObjectParm*, *=[0,7] ViewParm*, *=[0,7] AppParm*, *=[0,7] As the names imply the application sets an array of parameters in the renderer during the start of the rendering pass. Next, each renderview is rendered. This gives them a chance to set any ViewParms that they want. Finally, for each renderview, they render any visible objects. Each of the objects sets any of its ObjectParms before actually rendering its geometry. This gives three different levels of control to the shader parms. The app level is used for global constants, view is for renderview dependant parms, and object level is for per-object parms. So individual render views can set the appropriate parameters that they need. For question #2,

Quote:
What i'm trying to accomplish is a data-driven framework for configuring render-views. E.g. if i want a reflective object to use a dynamic cubemap, i should be able to specify this at the material level. This way i don't have to bother creating renderviews by hand after the object is loaded, and i can create new renderviews, without the need to inform the engine about it. Is this possible with your design?

This is possible, you just have to come up with a way of linking a specific render view with a material. In my system the render views are actually created and maintained within the objects, but you could create a separate material system to abstract the render views out of the objects control. This would make the object call 'SetMaterial( int index )' and the material system would have to manage the render views and so on. It's not a bad idea - perhaps Hieroglyph 2.0 will add something like this... I will make a copy of this and post it in the Graphics forum for everyone to check out. If you have any questions just let me know!

HellRaiZer

Jan 14, 2007 at 1:34 PM

Jason thanks for the reply.

Quote:
Original post by Jason Z
For question #1,
...

I think the original question wasn't clear. Sorry for the confusion. I'll try to explain what i was asking in more detail. I tried to keep it short but unfortunately this didn't helped.

Let's take for example a reflection CM render view. This render view gets the world as input and produces one cubemap. In order to work correctly, it also needs the position (and maybe the orientation) of the object that uses it. This, in case to place the 6 cameras at the object's position.

The first required input (the world) can be retrieved from the scene manager/renderer/whoever keeps such info. The second required thing (the cubemap texture) will be created during the rv's initialization. You can control the cubemap creation through a list of parameters (map) which you can pass to the initialization function (color bits of the cm texture, size of the cm, depth bits for the depth buffer, if you want to render shadows and recursive reflections from inside the cm, etc.)

My problem is, how it gets the last required input? The object that uses this cubemap (or to be more specific the position and orientation of the object).
I think you should assign this value at initialization time, because when you are updating the renderviews inside the renderer, every frame, you don't have that info.

The same as above applies to other render-views, such as a uniform shadow map rv which renders the scene from the light's pov. How do you pass the light's parameters to the rv?

What you describe about shaders is exactly what i'm doing, but this applies to shaders only, because shaders are suppose to work with any given input. So when it comes to setting up their parameters, you can query the values from whoever has them. View and application params should come from the renderer. Object params should come from the object (and its material). And this holds because the shader works with objects (even if the object is a full screen quad, it is an object).

I hope the above is more clear. If not let me know.

Thanks again for the reply.

HellRaiZer

Jason Z

Jan 14, 2007 at 3:31 PM

I understand what you are asking now. Each render view has an 'entity' pointer that it is considered to be 'attached' to. The render view would then read the entity's position/orientation and set those as a view parameter.

This could be implemented differently if you wanted, but my render views are controlled by the objects that create them. So if an object is going to use an environment map, it creates a EM render view and sends it to the renderer during the scene graph update pass.

In the case of a shadow map, the light object that creates the shadow map render view can either set the view parms directly in the render view or it would set itself as the render view's entity and the render view would set the view parms. In either case, the parameters are used to communicate the information from whoever has it to the rendering system, as well as object -> renderview.

Does this clear it up more?

HellRaiZer

Jan 15, 2007 at 12:53 AM

Thanks for clearing that up.

One last question though.

Quote:
Original post by Jason Z
Each render view has an 'entity' pointer that it is considered to be 'attached' to. The render view would then read the entity's position/orientation and set those as a view parameter.

Does this mean that the main render view (maybe a tree of render views for stacked post-process effects) is owned by the observer's camera? What happens if you attach a render view to an entity which don't have the required info (e.g. a shadow map render view to a model)? As i said i'm trying to implement a data-driven framework for the whole system, and mistakes like this should be easily avoidable by the design (i think at least).

Quote:

In the case of a shadow map, the light object that creates the shadow map render view can either set the view parms directly in the render view or ...

Doesn't this imply that the light knows which render view it is using? Does the abstract render view interface has helper (empty) functions for these things? How can an object knows what is needed by the render view without knowing the render view itself?

Thanks once again.

HellRaiZer

EDIT : I think i got it. The idea is to have specialized interfaces for each use. For example you may have an ObjectRenderView which is a renderview which requires an actual polygonal model in order to work (e.g. CMs, planar reflections, etc.), CameraRenderView, which is a renderview which requires a camera in order to work correctly (e.g. main render view, post-process render views, etc.) and a LightRenderView which is a renderview which can be attached to a light (e.g. shadowmap, VSM, stencil shadows, etc.)

I'll have to code it to see what i can get from it, but the idea seems doable and the possibility for erroneous rv assignments is kept to a minimum. E.g. Renderable objects should not keep a list of generic renderviews but a list of ObjectRenderView(s).

One point to note is that this approach works with my engine. In your engine, i don't know how you handle cameras and lights, and if they are any different from the other objects, so this may not apply to you.

Thanks again Jason for the help.

[Edited by - HellRaiZer on January 15, 2007 4:53:01 AM]

Jason Z

Jan 15, 2007 at 5:30 AM

HellRaiZer,

Quote:
EDIT : I think i got it. The idea is to have specialized interfaces for each use. For example you may have an ObjectRenderView which is a renderview which requires an actual polygonal model in order to work (e.g. CMs, planar reflections, etc.), CameraRenderView, which is a renderview which requires a camera in order to work correctly (e.g. main render view, post-process render views, etc.) and a LightRenderView which is a renderview which can be attached to a light (e.g. shadowmap, VSM, stencil shadows, etc.)

I'll have to code it to see what i can get from it, but the idea seems doable and the possibility for erroneous rv assignments is kept to a minimum. E.g. Renderable objects should not keep a list of generic renderviews but a list of ObjectRenderView(s).

This is one way to do it. Currently I rely on the programmer/designer to put render views in the correct places. However, I haven't ever had a situation where an incompatible type of render view can be sent to the renderer - there are no incompatible types.

For example, any node in the scene graph has a position and orientation, meaning that it can be used as the source of information for a shadow map rendering pass, cube map generation or whatever. I specifically design the system so that there are no incompatibilities.

However, you could abstract this to the material level as you mentioned, and use the material management system to select the proper render views for different hardware configs. Currently I use the render view to determine what shading LOD to use, but you could easily break this into the material system.

I am glad that this helped out - if you have any other questions just let me know.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.