Comments on: Intermediate rendering, or what goes into a feature

By: married dating guy

married dating guy — Sat, 21 May 2011 13:34:14 +0000

Thanks for taking the time to discuss this, I feel strongly about it and love learning extra on this topic. If possible, as you achieve expertise, would you mind updating your blog with extra info? This can be very useful for me.

By: Aras Pranckevičius

Aras Pranckevičius — Wed, 17 Sep 2008 06:13:38 +0000

@TomW: exactly, and that’s the point of this post. After one decides “ok, Draw() won’t actually draw, but merely add information to some list” – what implications does this decision have, how it interacts with all the other systems and so on.

By: TomW

TomW — Tue, 16 Sep 2008 21:24:46 +0000

Why not generate a list of things to draw; instead of draw() generating a list of things to draw. Say spatialSystem->GetListofVisible(&visibleEnts) entities.

This way you get the visibleEnts which you can filter for reflections, shadows, z only, post processing, other cameras, sort the list, maybe reuse the list next frame,etc.

Immeditate rendering, like you noticed with terrain, is hard because of the need to re-render,process or whatever later
-t

By: Aras Pranckevičius

Aras Pranckevičius — Sun, 20 Apr 2008 17:32:34 +0000

“It seems that a loop of a 1000 Draw() will generate only one draw call, is it correct?”
Not really. It will act just like 1000 objects were in the scene. So it might be much less draw calls, if some of those objects are not visible; or might even be more than 1000 draw calls, if the objects are affected by multiple pixel lights and/or are casting shadows, etc.

“Something which doesn’t show up in the explorer or the inspector might be tricky to debug, no?”
Maybe. This functionality is mostly for us, so that we can implement terrain+lighting properly, and for people who want to do something similar on their own. Yes, it is sort of “advanced” feature.

By: laurent

laurent — Fri, 18 Apr 2008 18:52:31 +0000

This is awesome!
It seems that a loop of a 1000 Draw() will generate only one draw call, is it correct?
Do you think it will draw bone deformed meshes as well?

Something which doesn’t show up in the explorer or the inspector might be tricky to debug, no ?
One solution, would be adding an IntermediateRender component which listens to all the Draw() calls in a similar way a NetworkView() listens to all the RPC. What do you think.

By: Dom

Dom — Thu, 20 Dec 2007 17:44:28 +0000

This is interesting. Although I don’t know much about renderer implementations, I can see that this is a challenge.
For me another aspect is interesting and that’s reusing components functionality. In Virtools there is a lot of functionality in Components (Behaviours/BuildingBlocks). The problem with this is when you need a variation or when you need ‘some’ functionality of that. Usually I wind up with copy/pasting the whole thing for creating my desired component variation, or I copy the few functions I want to use.
Pushing *some* functionality out of components into an API helps with re-usability which is funny because components is mostly about modularity and re-usability. In addition to that having to much inside an API may break lots of components when changing the API later. I guess the best is the middle of both worlds.