T3D rendering pipeline overview... getting a feel for things
by Daniel Buckmaster · in Torque 3D Beginner · 11/08/2014 (2:48 am) · 13 replies
Two things have happened today. First, I've realised that I don't know how SceneRenderState works. Second, someone's asked me about the structure of the rendering engine - how the scenegraph, rendering loop, and so on work, and I definitely knew I wasn't qualified to give a helpful answer.
So I'm wondering if any of the GFX gurus out there want to help me shed a little light on the subject. How does Torque go about getting data from the scene (the objects themselves) to the screen? The scene graph is a particularly interesting subject. Source code links or existing articles would be great. I'll collect any info on a wiki page so we can retain and build on it!
So I'm wondering if any of the GFX gurus out there want to help me shed a little light on the subject. How does Torque go about getting data from the scene (the objects themselves) to the screen? The scene graph is a particularly interesting subject. Source code links or existing articles would be great. I'll collect any info on a wiki page so we can retain and build on it!
About the author
Studying mechatronic engineering and computer science at the University of Sydney. Game development is probably my most time-consuming hobby!
#2
Every frame the render bins are cleared, then torque rolls through the scene graph and tells each object that its time to render. The objects submit render instances. Torque will then TRY to add the render instance to ALL of the bins. It's up to the bins to determine if they want that render instance or not. I think the glow bin is an excellent example of that:
github.com/GarageGames/Torque3D/blob/development/Engine/source/renderInstance/re...
As you can see it won't add an object that doesn't have glow enabled. Thus after this process is complete, each bin has a collection of objects it wants to render. Then, the bins are processed in the order defined in renderManager.cs in the core of projects. So, one by one they take the items they contain and each bin has it's own unique way of rendering based on it's purpose.
11/13/2014 (11:12 am)
Torque has render bins. A render bin holds render instances. Render instance is just a simple object that holds the data needed specifically to render that piece. They exist because they're lighter than dealing with the entire SimObject.Every frame the render bins are cleared, then torque rolls through the scene graph and tells each object that its time to render. The objects submit render instances. Torque will then TRY to add the render instance to ALL of the bins. It's up to the bins to determine if they want that render instance or not. I think the glow bin is an excellent example of that:
github.com/GarageGames/Torque3D/blob/development/Engine/source/renderInstance/re...
As you can see it won't add an object that doesn't have glow enabled. Thus after this process is complete, each bin has a collection of objects it wants to render. Then, the bins are processed in the order defined in renderManager.cs in the core of projects. So, one by one they take the items they contain and each bin has it's own unique way of rendering based on it's purpose.
#3
11/13/2014 (1:04 pm)
Clarified the query. Will post the conversation with permission as soon as we wrap up.
#4
Q): <snip>but what i wanna know
Q): is how the scene graph is made...and how exactly are you guys sending that data to the gpu
Q): i cannot quite get my head around the idea of having multiple VAO
Q): and VBOs
Q): and as far as i know a scene graph is a big tree
A): ok, so you're more looking for info on SceneManager::addObjectToScene and the like then
Q): im sorry and ashamed to say i really havent looked at the code for Torque
Q): or even used it
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L577 that'll be there
A): well, thing to remmber about torque is were talking an actual engine here, not a rendering plugin like a lot of other 'engines'. so opengl specifics aren't really necessairly relevant unless youre digging into portions that are wrapped by the GFX layer
Q): so you mean it has a sound, physics and all that good stuff...
Q): systems*
A): yep
Q): well, im more into the rendering part of it
A): not so much the physics. there its a bit of a mess between finished but limited stock physics and a physics plugin system that needs completion still
Q): like from the looks of it..you guys are trying to implement it using opengl
Q): or just change the back-end?
Q): am i right?
A): just change the back end opengl already present to flesh out the bindings and whatnot
A): https://github.com/GarageGames/Torque3D/milestones/OpenGL3 luis actually has those all listed under a tag for the PRs
A): but you wanted to know about scene management, in particular, yes?
Q): yes, lets say i wanna re make that tree...and play with it my self
A): ok.... this.. is gonna get involved...
Q): one thing though...im pretty okay with pointers too
Q): like give me a link to something i can read it
A): so again first up, that whole 'actual engine' thing is vital. scene != the whole mission. trust you already know that one
A): https://github.com/GarageGames/Torque3D/search?p=1&q=gClientSceneGraph&type=Code&utf8=%E2%9C%93 is the main hook to the scenegraph
Q): yup i know, from the words of Carmack, the sub section of the subsection that deals with putting pixels on the screen
A): yup. now for torque, theres 2 globals. the gClientSceneGraph, and the gServerSceneGraph. obviously the latter is used more for the authoritative physics and raycast end of things, as well as network ghosting and the like. follow?
Q): so what you mean is multiplayer stuff, the scenemanagers are different ?
Q): one is the server, and one is at the client side
Q): and they are updated differently but synced later..
A): kindasorta. technically with all present example, youre connecting to yourself so all you have to do for networking is flip a swtich to 'yes I'm accepting connections as well'
Q): so even offline...you still manage two scenes?
Q): updating to yourself ?
A): but yeah. for all intents and purposes, they're treated there as a parallel except server sends the occasional correction, yes.
Q): correction like what?
Q): what goes wrong that needs correcting?
A): well, say you've got two folks in motion and one hits a rock on one side
the othe on the other. server has to send the resulting motion of the rock to both players
A): or more classically: the guy connected to your server ducks and weaves. your client can't predict his motion without an update of what he did
Q): alright...seems fair..
Q): ah
A): so basically, the clientscenegraph is the one for guessing what's going on, the server is the one for knowing it and letting clients know. follow?
A): (keeps the game from stalling out or flooding the network trying to keep everything updated constantly)
Q): yes, but wouldnt the actual stuff happen at one client, then sent to a server then back to others ?
A): for cheat prevention, the only thing happening on a given client that isn't also a server is goin "I pushed the fire button" or "I hit WASD"
A): though again, the clientscenegraphs goes ahead and simulates what *should* happen between being corrected as far as what *did*
Q): ah...alright...seems good...so far..
11/13/2014 (1:36 pm)
PT1)Q): <snip>but what i wanna know
Q): is how the scene graph is made...and how exactly are you guys sending that data to the gpu
Q): i cannot quite get my head around the idea of having multiple VAO
Q): and VBOs
Q): and as far as i know a scene graph is a big tree
A): ok, so you're more looking for info on SceneManager::addObjectToScene and the like then
Q): im sorry and ashamed to say i really havent looked at the code for Torque
Q): or even used it
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L577 that'll be there
A): well, thing to remmber about torque is were talking an actual engine here, not a rendering plugin like a lot of other 'engines'. so opengl specifics aren't really necessairly relevant unless youre digging into portions that are wrapped by the GFX layer
Q): so you mean it has a sound, physics and all that good stuff...
Q): systems*
A): yep
Q): well, im more into the rendering part of it
A): not so much the physics. there its a bit of a mess between finished but limited stock physics and a physics plugin system that needs completion still
Q): like from the looks of it..you guys are trying to implement it using opengl
Q): or just change the back-end?
Q): am i right?
A): just change the back end opengl already present to flesh out the bindings and whatnot
A): https://github.com/GarageGames/Torque3D/milestones/OpenGL3 luis actually has those all listed under a tag for the PRs
A): but you wanted to know about scene management, in particular, yes?
Q): yes, lets say i wanna re make that tree...and play with it my self
A): ok.... this.. is gonna get involved...
Q): one thing though...im pretty okay with pointers too
Q): like give me a link to something i can read it
A): so again first up, that whole 'actual engine' thing is vital. scene != the whole mission. trust you already know that one
A): https://github.com/GarageGames/Torque3D/search?p=1&q=gClientSceneGraph&type=Code&utf8=%E2%9C%93 is the main hook to the scenegraph
Q): yup i know, from the words of Carmack, the sub section of the subsection that deals with putting pixels on the screen
A): yup. now for torque, theres 2 globals. the gClientSceneGraph, and the gServerSceneGraph. obviously the latter is used more for the authoritative physics and raycast end of things, as well as network ghosting and the like. follow?
Q): so what you mean is multiplayer stuff, the scenemanagers are different ?
Q): one is the server, and one is at the client side
Q): and they are updated differently but synced later..
A): kindasorta. technically with all present example, youre connecting to yourself so all you have to do for networking is flip a swtich to 'yes I'm accepting connections as well'
Q): so even offline...you still manage two scenes?
Q): updating to yourself ?
A): but yeah. for all intents and purposes, they're treated there as a parallel except server sends the occasional correction, yes.
Q): correction like what?
Q): what goes wrong that needs correcting?
A): well, say you've got two folks in motion and one hits a rock on one side
the othe on the other. server has to send the resulting motion of the rock to both players
A): or more classically: the guy connected to your server ducks and weaves. your client can't predict his motion without an update of what he did
Q): alright...seems fair..
Q): ah
A): so basically, the clientscenegraph is the one for guessing what's going on, the server is the one for knowing it and letting clients know. follow?
A): (keeps the game from stalling out or flooding the network trying to keep everything updated constantly)
Q): yes, but wouldnt the actual stuff happen at one client, then sent to a server then back to others ?
A): for cheat prevention, the only thing happening on a given client that isn't also a server is goin "I pushed the fire button" or "I hit WASD"
A): though again, the clientscenegraphs goes ahead and simulates what *should* happen between being corrected as far as what *did*
Q): ah...alright...seems good...so far..
#5
Q): how about we focus on the server for now...as the cool stuff goes on there..
Q): and remove everything...lets get to the bare metal
Q): at its core...we have a tree structure right?
A): essentially, yeah
Q): okay...so I have a tree...
Q): the nodes...
Q): what are they?
Q): what is there struct ?
Q): and what does it contain?
A): ok. remmber that link to SceneManager::addObjectToScene earlier?
Q): yup
Q): we have a scene object
A): ok, so backing up a bit first:
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L58 is the global server scene class hook
A): you'll note again that SceneManager is a SceneManager is a SceneManager for that purpose
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L591 leads us to https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneContainer.cpp#L226 for the bin(node) system
Q): the last link is a bit complex to get my head around
A): sok, we'll get to it. short version is the thing splits it into 'branches' at that point to use your tree analogy
A): btw, mind if I go ahead and post this on the forums later?
Q): post what?
A): the convo
Q): sure
Q): but one thing...are you not bored ?
Q): am i taking too much of your time?
A): look at it this way: you ask enough of the right questions, I don't have to keep re-explaining it to the next guy :P
A): one of the reasons I asked about forum-posting it
Q): ohh...the right questions...
Q): right...
A): 'right' being 'wtf did I just read. this is not self explainatory help' :P
A): so anyway, in scenecontainer, you'll also find a https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneContainer.cpp#L414 method
A): were getting to the scene display bit shortly btw
A): ok, so we left off at SceneContainer::findObjects
A): void SceneManager::scopeScene( CameraScopeQuery* query, NetConnection* netConnection ) goes back to the prior class a bit. that's https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L544 and you can see from the method signature https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L572 is where that's tied togeather to the camera
A): loose you?
Q): oh sorry reading some code
A): heh. not about to complain about *that* :P
Q): reading code is like starting a story mid way...
Q): you have to jump back and forth to get it
A): yeah. that's why this particular journey started as low as it did. context
A): also why most of my convos are link-heavy
Q): this will help me most when i look back to it...
Q): right now it feels like a puzzle
Q): so one sec to refresh my memory with those stuff
A): rgr. say when and I'll drop more on you. getting to the part where it starts in on per-object
Q): so sorry for taking your time...and having so little knowledge about this stuff
Q): i will go through this again...and report back
Q): and see if i got it or not
A): honestly, most don't. half the reason I'm glad to take the time is so we can fill in the doc blanks
Q): ah..i hope its usefull for you guys..
A): so anyway, that scopescne is used in SceneObject::onCameraScopeQuery like so: https://github.com/GarageGames/Torque3D/blob/889d5122cce5a46c5d3e0086d50f33a4f139345d/Engine/source/scene/sceneObject.cpp#L681 (you'll notice for clients it gets into what's displayed that way and for servers it just snags it)
A): NetObject::onCameraScopeQuery (which is a parent of sceneobject) is where the ghosting magic happens. we'll blow through that at a later date
11/13/2014 (1:38 pm)
Pt2)Q): how about we focus on the server for now...as the cool stuff goes on there..
Q): and remove everything...lets get to the bare metal
Q): at its core...we have a tree structure right?
A): essentially, yeah
Q): okay...so I have a tree...
Q): the nodes...
Q): what are they?
Q): what is there struct ?
Q): and what does it contain?
A): ok. remmber that link to SceneManager::addObjectToScene earlier?
Q): yup
Q): we have a scene object
A): ok, so backing up a bit first:
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L58 is the global server scene class hook
A): you'll note again that SceneManager is a SceneManager is a SceneManager for that purpose
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L591 leads us to https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneContainer.cpp#L226 for the bin(node) system
Q): the last link is a bit complex to get my head around
A): sok, we'll get to it. short version is the thing splits it into 'branches' at that point to use your tree analogy
A): btw, mind if I go ahead and post this on the forums later?
Q): post what?
A): the convo
Q): sure
Q): but one thing...are you not bored ?
Q): am i taking too much of your time?
A): look at it this way: you ask enough of the right questions, I don't have to keep re-explaining it to the next guy :P
A): one of the reasons I asked about forum-posting it
Q): ohh...the right questions...
Q): right...
A): 'right' being 'wtf did I just read. this is not self explainatory help' :P
A): so anyway, in scenecontainer, you'll also find a https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneContainer.cpp#L414 method
A): were getting to the scene display bit shortly btw
A): ok, so we left off at SceneContainer::findObjects
A): void SceneManager::scopeScene( CameraScopeQuery* query, NetConnection* netConnection ) goes back to the prior class a bit. that's https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L544 and you can see from the method signature https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L572 is where that's tied togeather to the camera
A): loose you?
Q): oh sorry reading some code
A): heh. not about to complain about *that* :P
Q): reading code is like starting a story mid way...
Q): you have to jump back and forth to get it
A): yeah. that's why this particular journey started as low as it did. context
A): also why most of my convos are link-heavy
Q): this will help me most when i look back to it...
Q): right now it feels like a puzzle
Q): so one sec to refresh my memory with those stuff
A): rgr. say when and I'll drop more on you. getting to the part where it starts in on per-object
Q): so sorry for taking your time...and having so little knowledge about this stuff
Q): i will go through this again...and report back
Q): and see if i got it or not
A): honestly, most don't. half the reason I'm glad to take the time is so we can fill in the doc blanks
Q): ah..i hope its usefull for you guys..
A): so anyway, that scopescne is used in SceneObject::onCameraScopeQuery like so: https://github.com/GarageGames/Torque3D/blob/889d5122cce5a46c5d3e0086d50f33a4f139345d/Engine/source/scene/sceneObject.cpp#L681 (you'll notice for clients it gets into what's displayed that way and for servers it just snags it)
A): NetObject::onCameraScopeQuery (which is a parent of sceneobject) is where the ghosting magic happens. we'll blow through that at a later date
#6
Q): okay...
Q): can we go back to the sceneContainer...
A): sure. which bit?
Q): what is its exact relation to the Scene manager..
A): talking that getContainer()->addObject( object ); bit from earlier, right?
A): SceneContainer* getContainer() const { return mIsClient ? &gClientContainer : &gServerContainer; }
Q): let me just look up addObject...and look at its body
A): that's the one does the insertIntoBins bit (those 'branches' we talked about earlier
Q): yup i see that now...but it does some extra checking as well...kinda aiming for the full story here
A): if ( obj->getTypeMask() & ( WaterObjectType | PhysicalZoneObjectType ) ) that bit?
A): Vector< SceneObject* > mWaterAndZones;
Q): na..just the function as a whole...but that part sounds like if its water or some thing physics related the bins are different
A): /// Return the type mask that indicates to which broad object categories /// this object belongs. U32 getTypeMask() const { return mTypeMask; }
A): yup
A): the linkafter bit is pretty much your typical linked list
Q): yeah...glad to see something i can relate to :p
A): heh. the bins bit... are you generally familiar with the principle behind http://en.wikipedia.org/wiki/Binary_space_partitioning ? (link for the folks playing the home game later)
Q): ah, i remember george talking about that...
Q): Binary searching in 3D
A): yep. you never want your entire world in one spot. that'd be search size hell
A): so generally speaking you break it up into manageable portions. that's where the tree structure generally comes in. nodes as you seem to understand them being the final stage on the list
Q): so when inserting a new obj...it goes into a diff bin based on its box?
A): basically, yeah. that way you don't have to render something 2k units behind you that you've no chance of ever seeing
A): (or even network it. but again, that's a whole topic on it's own)
Q): but why only x and y...where does z come in?
A): yknow. that's a good question. looks like they opted for a topdown method for simplicity of implementation there
Q): looks like BSP uses planes
Q): and either im wrong or not...but an x and y can define a plane..if z is move in increments..
A): yeah. it's not a 1:1 correlation. just a general method of thought
Q): alright...seems good enough...one other thing
Q): if it already has an object in a partition...it adds it to that place...but if not it creates a new SceneObjectRef ?
A): pretty much yeah. depending on if a given object is moved it can also be set to dirty and shifted to a different bin
Q): owww...noice...
Q): okay...let me get back to the story
Q): what comes after the bins..
A): ok, so after it's in the bins, there's that bit from earlier about SceneContainer::findObjects that can hunt through the things and generate a list based on an area
Q): and when finding an object...the mask defines where to looks as in water or physics obj
Q): and it does so based on an area box3f
A): for those very specie snowflake cases, yes. largely because those are objects you won't not expect to be able to be broken up
A): er. would not expect. pardon
Q): alright...so i need tp check on my Data structures
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneContainer.cpp#L244 actually, that bit goes into it fairly well there
A): note the whole isGlobalBounds bit for yet more options for things not to stick into a subdivision, but in the 'main trunk' as it were
A): cornercase, but can crop up time to time
11/13/2014 (1:39 pm)
Pt3)Q): okay...
Q): can we go back to the sceneContainer...
A): sure. which bit?
Q): what is its exact relation to the Scene manager..
A): talking that getContainer()->addObject( object ); bit from earlier, right?
A): SceneContainer* getContainer() const { return mIsClient ? &gClientContainer : &gServerContainer; }
Q): let me just look up addObject...and look at its body
A): that's the one does the insertIntoBins bit (those 'branches' we talked about earlier
Q): yup i see that now...but it does some extra checking as well...kinda aiming for the full story here
A): if ( obj->getTypeMask() & ( WaterObjectType | PhysicalZoneObjectType ) ) that bit?
A): Vector< SceneObject* > mWaterAndZones;
Q): na..just the function as a whole...but that part sounds like if its water or some thing physics related the bins are different
A): /// Return the type mask that indicates to which broad object categories /// this object belongs. U32 getTypeMask() const { return mTypeMask; }
A): yup
A): the linkafter bit is pretty much your typical linked list
Q): yeah...glad to see something i can relate to :p
A): heh. the bins bit... are you generally familiar with the principle behind http://en.wikipedia.org/wiki/Binary_space_partitioning ? (link for the folks playing the home game later)
Q): ah, i remember george talking about that...
Q): Binary searching in 3D
A): yep. you never want your entire world in one spot. that'd be search size hell
A): so generally speaking you break it up into manageable portions. that's where the tree structure generally comes in. nodes as you seem to understand them being the final stage on the list
Q): so when inserting a new obj...it goes into a diff bin based on its box?
A): basically, yeah. that way you don't have to render something 2k units behind you that you've no chance of ever seeing
A): (or even network it. but again, that's a whole topic on it's own)
Q): but why only x and y...where does z come in?
A): yknow. that's a good question. looks like they opted for a topdown method for simplicity of implementation there
Q): looks like BSP uses planes
Q): and either im wrong or not...but an x and y can define a plane..if z is move in increments..
A): yeah. it's not a 1:1 correlation. just a general method of thought
Q): alright...seems good enough...one other thing
Q): if it already has an object in a partition...it adds it to that place...but if not it creates a new SceneObjectRef ?
A): pretty much yeah. depending on if a given object is moved it can also be set to dirty and shifted to a different bin
Q): owww...noice...
Q): okay...let me get back to the story
Q): what comes after the bins..
A): ok, so after it's in the bins, there's that bit from earlier about SceneContainer::findObjects that can hunt through the things and generate a list based on an area
Q): and when finding an object...the mask defines where to looks as in water or physics obj
Q): and it does so based on an area box3f
A): for those very specie snowflake cases, yes. largely because those are objects you won't not expect to be able to be broken up
A): er. would not expect. pardon
Q): alright...so i need tp check on my Data structures
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneContainer.cpp#L244 actually, that bit goes into it fairly well there
A): note the whole isGlobalBounds bit for yet more options for things not to stick into a subdivision, but in the 'main trunk' as it were
A): cornercase, but can crop up time to time
#7
Q): oh okay...
Q): one sec...i think i lost the bookmark of the story...
A): so ok, already went over SceneManager::scopeScene and how that ties on in.
Q): im stuck there...let me catch up :P
Q): ummm...i didnt get that whole method signature
Q): so that scopeScene will get us the objects as defined by the camerascopeqeury which are visible
A): ok, so NetConnection* netConnection is the connection the server is tracking for a given client (remmber, that's built in) CameraScopeQuery* query you'll find https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/sim/netObject.h#L40
A): essentially. pads it a bit so the netwrok doesn't hork horribly and pop things into viw on you out of nowhere, but thats the gist
Q): so get the objects and center the view
Q): what is special about that mask? does it define terrain?
A): which?
Q): getContainer()->findObjects( area, 0xFFFFFFFF, _scopeCallback, &info );
Q): the second param..is a mask right?
A): ah yes. that bit. yeah. the 0xf bit's basically saying 'check em all'
Q): thought as far...good
A): by all, I'm referring to https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/T3D/objectTypes.h#L32 (bitwise listing so things can be of more than one type)
A): so ok, we've got one practical example of simply going 'ok, you're in range of the camera now ghost to the client' now we get into SceneManager::_renderScene
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L354 the that bit
A): we'll skip over zones a bit as those are pretty much just another form of bin. albeit one you can specify the extents of
Q): okay...one moment until i get some mess out of my hands...
Q): i didnt plan for this but a problem came up at uni and i have to attend to...and as a guy my brain cannot multi task
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/zones/sceneSimpleZone.cpp#L273 actually, that one's probably pretty important to note as a distinction come to think of it. (SceneSimpleZone::traverseZones)
Had to stop for the day at that point. Tune in next time for more "What do real people trying to learn the engine struggle with."
11/13/2014 (1:40 pm)
pt4)Q): oh okay...
Q): one sec...i think i lost the bookmark of the story...
A): so ok, already went over SceneManager::scopeScene and how that ties on in.
Q): im stuck there...let me catch up :P
Q): ummm...i didnt get that whole method signature
Q): so that scopeScene will get us the objects as defined by the camerascopeqeury which are visible
A): ok, so NetConnection* netConnection is the connection the server is tracking for a given client (remmber, that's built in) CameraScopeQuery* query you'll find https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/sim/netObject.h#L40
A): essentially. pads it a bit so the netwrok doesn't hork horribly and pop things into viw on you out of nowhere, but thats the gist
Q): so get the objects and center the view
Q): what is special about that mask? does it define terrain?
A): which?
Q): getContainer()->findObjects( area, 0xFFFFFFFF, _scopeCallback, &info );
Q): the second param..is a mask right?
A): ah yes. that bit. yeah. the 0xf bit's basically saying 'check em all'
Q): thought as far...good
A): by all, I'm referring to https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/T3D/objectTypes.h#L32 (bitwise listing so things can be of more than one type)
A): so ok, we've got one practical example of simply going 'ok, you're in range of the camera now ghost to the client' now we get into SceneManager::_renderScene
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L354 the that bit
A): we'll skip over zones a bit as those are pretty much just another form of bin. albeit one you can specify the extents of
Q): okay...one moment until i get some mess out of my hands...
Q): i didnt plan for this but a problem came up at uni and i have to attend to...and as a guy my brain cannot multi task
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/zones/sceneSimpleZone.cpp#L273 actually, that one's probably pretty important to note as a distinction come to think of it. (SceneSimpleZone::traverseZones)
Had to stop for the day at that point. Tune in next time for more "What do real people trying to learn the engine struggle with."
#8
A): where were we?
Q): we were at _renderScene stuff
A): ok. so. first up to be clear, SceneManager::_renderScene is pretty much the most basic of that particular family of methods. theres 3 we'll be goin over of a bit more complexity but first we wrap your head around that one
Q): can you relink it...
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L354
A): so theres a few things to be aware of that are highlighted here. passes and zones
Q): jesus this one is big
Q): wait...as far as i understand it...this is what it does:
Q): we have a base object for a scene
Q): and this goes through that part of the tree starting from the base
Q): and just renders what might be visible from the bases point of view
A): essentially, yep
A): so. note: if( gEditingMission && state->isDiffusePass() )
A): there's a couple things going on there. first another global flipped on when you hit f10 and hop into the in-game editor. second is checking to see if you are presently on th
A): for instance torque (at this point) uses what's called prepass lighting. this is as oposed to forward lit, or a more fully deferred pipeline. which is where that pass check comes in. how much of that requires explanation expansion?
Q): one sec
Q): that line...i don't have enough info to decode it...so pretty much everything there needs explanation
A): ok, so short history lesson then. first came forward lit, where you just took your scenegraph, threw everything in range at it and rendered back to front. biggest issue with that one is what's called overdraw, because youre drawing over what you already rendered. follow?
A): (this actually ties in to a hefty PR in the queue so a more full explanation is perfectly fine by me)
Q): if you have the time for it
A): now at time of writing, that forward lit bit is still the case for translucent objects, since you've got to render what's behind them.
Q): ah something deferred lighting fails at
A): exactly
Q): cool...so we pay a toll for having alpha
Q): or get a speed boost where we don't have it
11/14/2014 (3:32 pm)
pt5)A): where were we?
Q): we were at _renderScene stuff
A): ok. so. first up to be clear, SceneManager::_renderScene is pretty much the most basic of that particular family of methods. theres 3 we'll be goin over of a bit more complexity but first we wrap your head around that one
Q): can you relink it...
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L354
A): so theres a few things to be aware of that are highlighted here. passes and zones
Q): jesus this one is big
Q): wait...as far as i understand it...this is what it does:
Q): we have a base object for a scene
Q): and this goes through that part of the tree starting from the base
Q): and just renders what might be visible from the bases point of view
A): essentially, yep
A): so. note: if( gEditingMission && state->isDiffusePass() )
A): there's a couple things going on there. first another global flipped on when you hit f10 and hop into the in-game editor. second is checking to see if you are presently on th
A): for instance torque (at this point) uses what's called prepass lighting. this is as oposed to forward lit, or a more fully deferred pipeline. which is where that pass check comes in. how much of that requires explanation expansion?
Q): one sec
Q): that line...i don't have enough info to decode it...so pretty much everything there needs explanation
A): ok, so short history lesson then. first came forward lit, where you just took your scenegraph, threw everything in range at it and rendered back to front. biggest issue with that one is what's called overdraw, because youre drawing over what you already rendered. follow?
A): (this actually ties in to a hefty PR in the queue so a more full explanation is perfectly fine by me)
Q): if you have the time for it
A): now at time of writing, that forward lit bit is still the case for translucent objects, since you've got to render what's behind them.
Q): ah something deferred lighting fails at
A): exactly
Q): cool...so we pay a toll for having alpha
Q): or get a speed boost where we don't have it
#9
A): yep. now historically, the next tech improvement was deferred shading, that one takes lighting data and color data and sticks them in what's called a gbuffer, then when it comes time to render the scene, stiches the data back together for a final render.
Q): ah okay...
A): a gbuffer is basically one or more buffers of texture data of screen size dimension that's flipped to the screen, not unlike the truly old backbuffer system that you'll find as early as rasterizers
A): difference being of course the data is passed along to another buffer first for interpretation. follow?
Q): let me see
Q): so data is split as need into different gbuffers and later like you said is put back together...
A): it's referred to as a singular buffer, but yeah
Q): wonder why i havent heared about this stuff in some books...maybe these are very new? or im just reading old stuff
A): so moving on to prepass lighting to illustrate the difference there: with prepass, lighting data is cobbled togeather into a gbuffer then rendered to the scene, then color data is modulated onto the result. (this particular bit of tech cropped up as early as... want to say at least 2006-2009)
Q): ah okay...
Q): my knowledge as far as it come to lighting it can only extend to simple phong model
A): sok, torque actually still uses blinn-phong
A): rather obviously, with less to store that shrunk the gbuffer on down from 2-3 screen size buffers to 1, at the cost of loosing the capacity to retrieve pre-multiplied data
Q): that last few lines seem heavy to grasp
A): ok. so. buffer vs gbuffer and prepass vs deferred... know what a backbuffer is?
Q): draw on the backbuffer and then swap with front buffer
Q): for animations and to avoid tearing
A): right. a gbuffer is a glorified backbuffer. may be of backbufferSize*2-3 depending on how much additional data you're storing back there before sending it to the backbuffer before flipping ot the screen
Q): so bigger than the back buffer?
Q): and it shrunk down to fit?
A): usually comprises a series of what are called render targets (memory based 'textures')
Q): why? faster ?
A): sorta. say RT1 holds your normals and depth info for a scene, RT2 your color, RT3 your specular and gloss settings to list off what we did with the deferred branch in a simple manner
A): so not so much 'shrunk' as 'holds particular info for all of the objects displayed'
A): then combined later, be it via a screen-sized final shader, or, as with prepass lighting, done on top of the previous result. aka renderpass
Q): hmm...makes some sense
A): depending on what your combination end goal is (forward lit, deferred, or prepass, or even the newest notion, forward+ which we'll skip on over) determines how you need to write to and from your glsl files.
A): (tolja that'd tie in :P)
Q): so let me get this right
Q): we get all over stuff ready...
Q): like normals, and other stuff
Q): and put them into "gbuffers"
Q): then do calculation on them..based on what we want
Q): and then send them to the shaders
A): singular, and shaders feed the gbuffer first, then feed from it
A): but the general notion is correct
Q): write to the buffer and then re read from it
A): yup
Q): and i thought that was bad?
Q): wait the data is still in the gpu right?
A): no more bad than any other variable replacement method. temp = a; a=b; b=temp;
A): right. still on the gpu
Q): okay...
A): in this case, the 'replacement method' is a bit more complex. more like temp = a+b+c; d=temp; a=d;
11/14/2014 (3:33 pm)
pt6)A): yep. now historically, the next tech improvement was deferred shading, that one takes lighting data and color data and sticks them in what's called a gbuffer, then when it comes time to render the scene, stiches the data back together for a final render.
Q): ah okay...
A): a gbuffer is basically one or more buffers of texture data of screen size dimension that's flipped to the screen, not unlike the truly old backbuffer system that you'll find as early as rasterizers
A): difference being of course the data is passed along to another buffer first for interpretation. follow?
Q): let me see
Q): so data is split as need into different gbuffers and later like you said is put back together...
A): it's referred to as a singular buffer, but yeah
Q): wonder why i havent heared about this stuff in some books...maybe these are very new? or im just reading old stuff
A): so moving on to prepass lighting to illustrate the difference there: with prepass, lighting data is cobbled togeather into a gbuffer then rendered to the scene, then color data is modulated onto the result. (this particular bit of tech cropped up as early as... want to say at least 2006-2009)
Q): ah okay...
Q): my knowledge as far as it come to lighting it can only extend to simple phong model
A): sok, torque actually still uses blinn-phong
A): rather obviously, with less to store that shrunk the gbuffer on down from 2-3 screen size buffers to 1, at the cost of loosing the capacity to retrieve pre-multiplied data
Q): that last few lines seem heavy to grasp
A): ok. so. buffer vs gbuffer and prepass vs deferred... know what a backbuffer is?
Q): draw on the backbuffer and then swap with front buffer
Q): for animations and to avoid tearing
A): right. a gbuffer is a glorified backbuffer. may be of backbufferSize*2-3 depending on how much additional data you're storing back there before sending it to the backbuffer before flipping ot the screen
Q): so bigger than the back buffer?
Q): and it shrunk down to fit?
A): usually comprises a series of what are called render targets (memory based 'textures')
Q): why? faster ?
A): sorta. say RT1 holds your normals and depth info for a scene, RT2 your color, RT3 your specular and gloss settings to list off what we did with the deferred branch in a simple manner
A): so not so much 'shrunk' as 'holds particular info for all of the objects displayed'
A): then combined later, be it via a screen-sized final shader, or, as with prepass lighting, done on top of the previous result. aka renderpass
Q): hmm...makes some sense
A): depending on what your combination end goal is (forward lit, deferred, or prepass, or even the newest notion, forward+ which we'll skip on over) determines how you need to write to and from your glsl files.
A): (tolja that'd tie in :P)
Q): so let me get this right
Q): we get all over stuff ready...
Q): like normals, and other stuff
Q): and put them into "gbuffers"
Q): then do calculation on them..based on what we want
Q): and then send them to the shaders
A): singular, and shaders feed the gbuffer first, then feed from it
A): but the general notion is correct
Q): write to the buffer and then re read from it
A): yup
Q): and i thought that was bad?
Q): wait the data is still in the gpu right?
A): no more bad than any other variable replacement method. temp = a; a=b; b=temp;
A): right. still on the gpu
Q): okay...
A): in this case, the 'replacement method' is a bit more complex. more like temp = a+b+c; d=temp; a=d;
#10
A): we've gone a bit without feeding my link addiction, so: https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.h#L75 would be why I explicitly used 3 values there
A): which is what ties us back to that if( gEditingMission && state->isDiffusePass() ) line
Q): oh links
A): yup. now for all intents and purposes, the present torque pipeline follows SPT_Shadow+SPT_Diffuse with SPT_Reflect = SPT_Diffuse*SPT_Diffuse.A and another layer of SPT_Diffuse on top of that for reflections. (it's being simplified later for both artists and coders)
A): well, actually, more like a mul for the shadow and diffuse combination, but you get the drift
A): so we've gone over the baseline renderscene, and covered passes, this next series should make a bit more sense
Q): hmm...this is getting weird...are we just multipling data to get the correct coloring and shadow stuff?
A): handwaving the actual math a bit for now since that'll be in flux soon
Q): i know...freaking math
A): so: https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/T3D/gameTSCtrl.cpp#L73 where GameTSCtrl is the gui element you add to a scene to display the 3d 'in game' gui.
A): leads us to https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/T3D/gameFunctions.cpp#L406
A): leds us to https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L146
A): ends up in https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L185
A): SceneManager::renderSceneNoLights being where the ultra-simplified _renderScene comes back into play to go full-circle there
Q): wait..that GameTSCtrl::renderworld
Q): what does it do with its param ?
A): ignores it. perils of dealing with a mature codebase. (***editors note: on re-review, this was incorrect. it's actually overridden by child classes. we touch on that later***)
Q): this line "GameTSCtrl is the gui element you add to a scene to display the 3d 'in game' gui."
Q): what does GUI & 3D 'in game' mean exactly
A): it means the 3d scene displayed in 2d format
A): you'll note if you crack open the gui editor (f10) and maximize the editor the 3d scene is displayed on just another gui. albeit a rather complex one
11/14/2014 (3:35 pm)
pt7)A): we've gone a bit without feeding my link addiction, so: https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.h#L75 would be why I explicitly used 3 values there
A): which is what ties us back to that if( gEditingMission && state->isDiffusePass() ) line
Q): oh links
A): yup. now for all intents and purposes, the present torque pipeline follows SPT_Shadow+SPT_Diffuse with SPT_Reflect = SPT_Diffuse*SPT_Diffuse.A and another layer of SPT_Diffuse on top of that for reflections. (it's being simplified later for both artists and coders)
A): well, actually, more like a mul for the shadow and diffuse combination, but you get the drift
A): so we've gone over the baseline renderscene, and covered passes, this next series should make a bit more sense
Q): hmm...this is getting weird...are we just multipling data to get the correct coloring and shadow stuff?
A): handwaving the actual math a bit for now since that'll be in flux soon
Q): i know...freaking math
A): so: https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/T3D/gameTSCtrl.cpp#L73 where GameTSCtrl is the gui element you add to a scene to display the 3d 'in game' gui.
A): leads us to https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/T3D/gameFunctions.cpp#L406
A): leds us to https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L146
A): ends up in https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/scene/sceneManager.cpp#L185
A): SceneManager::renderSceneNoLights being where the ultra-simplified _renderScene comes back into play to go full-circle there
Q): wait..that GameTSCtrl::renderworld
Q): what does it do with its param ?
A): ignores it. perils of dealing with a mature codebase. (***editors note: on re-review, this was incorrect. it's actually overridden by child classes. we touch on that later***)
Q): this line "GameTSCtrl is the gui element you add to a scene to display the 3d 'in game' gui."
Q): what does GUI & 3D 'in game' mean exactly
A): it means the 3d scene displayed in 2d format
A): you'll note if you crack open the gui editor (f10) and maximize the editor the 3d scene is displayed on just another gui. albeit a rather complex one
#11
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/gui/3d/guiTSControl.cpp#L304 is the secondary system that functions in parallel to the other btw. we'll be going over that bit next
Q): okay...just checking...i see that GuiTCtrl now, and i think im getting a more feel to it
A): rgr. so to step back a bit higher for context, GuiCanvas::renderFrame contains a https://github.com/GarageGames/Torque3D/blob/3082bb3adc75134dc4cba2e1787b8ec838771ed5/Engine/source/gui/core/guiCanvas.cpp#L1759 which is where that ties on in
A): we'll handwave canvas for now and just call it a window to keep things simple there
A): so you'll see on top of that GuiTSCtrl::onRender that whole if(!processCameraQuery(&mLastCameraQuery)) bit that we went over yesterday for prefiltering
A): getCurrentRenderStyle is a switch for single or left and right (occulous support) just as an fyi
Q): wait...i dont see that if statement
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/gui/3d/guiTSControl.cpp#L304 (repost)
Q): alright..i get it now..
Q): check if there is a camera...if not then its pure gui
Q): or the point just went over me?
A): eh, basically, yeah
A): the actual camera query is defined in GameTSCtrl::processCameraQuery which is a child class, but most of the relevant guts are in this superclass, so focusing there for the moment
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/T3D/gameTSCtrl.cpp#L66 linky for lookup later
A): (also note of course, theres where that GameRenderWorld bit from the other day ties in. like I said, these two run in parallel)
Q): ah...
A): bit of a snarl there, yeah
A): so moving right along on this superclass breakdown, with a few more notes, that bit is also where the REFLECTMGR->update (reflection controller) ties in, gClientSceneGraph->setDisplayTargetResolution ect
Q): refelect manager is doing light reflection or what?
A): full scene reflection
A): ie: the view of the scene from a waters surface, or a dynamicly generated cubemap
Q): ah
11/14/2014 (3:37 pm)
pt8)A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/gui/3d/guiTSControl.cpp#L304 is the secondary system that functions in parallel to the other btw. we'll be going over that bit next
Q): okay...just checking...i see that GuiTCtrl now, and i think im getting a more feel to it
A): rgr. so to step back a bit higher for context, GuiCanvas::renderFrame contains a https://github.com/GarageGames/Torque3D/blob/3082bb3adc75134dc4cba2e1787b8ec838771ed5/Engine/source/gui/core/guiCanvas.cpp#L1759 which is where that ties on in
A): we'll handwave canvas for now and just call it a window to keep things simple there
A): so you'll see on top of that GuiTSCtrl::onRender that whole if(!processCameraQuery(&mLastCameraQuery)) bit that we went over yesterday for prefiltering
A): getCurrentRenderStyle is a switch for single or left and right (occulous support) just as an fyi
Q): wait...i dont see that if statement
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/gui/3d/guiTSControl.cpp#L304 (repost)
Q): alright..i get it now..
Q): check if there is a camera...if not then its pure gui
Q): or the point just went over me?
A): eh, basically, yeah
A): the actual camera query is defined in GameTSCtrl::processCameraQuery which is a child class, but most of the relevant guts are in this superclass, so focusing there for the moment
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/T3D/gameTSCtrl.cpp#L66 linky for lookup later
A): (also note of course, theres where that GameRenderWorld bit from the other day ties in. like I said, these two run in parallel)
Q): ah...
A): bit of a snarl there, yeah
A): so moving right along on this superclass breakdown, with a few more notes, that bit is also where the REFLECTMGR->update (reflection controller) ties in, gClientSceneGraph->setDisplayTargetResolution ect
Q): refelect manager is doing light reflection or what?
A): full scene reflection
A): ie: the view of the scene from a waters surface, or a dynamicly generated cubemap
Q): ah
#12
A): so we left off at setDisplayTargetResolution. next significant bit is that's where she sets the GFX->setWorldMatrix( worldToCamera );, mSaveProjection = GFX->getProjectionMatrix(); etc so that during rendering it'll know where the camera needs to be in terms of trasnlation, rotation, Field of view etc in order to form a rendering frusutm (the bounds of the scene used to determine what all renders)
Q): that part i undertand...
Q): matrix fun...
A): PFXMGR->setFrameMatrices( mSaveModelview, mSaveProjection ); postfx subsystem hook. (paraphrasing) this is where it tells the screenspaced sized quads that are layered on top of everything relevant bits of data they'll need to know later as well
Q): what is frameMatrices never heard of them...but is it just multiplying the projection and the model view matrix?
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/postFx/postEffectManager.cpp#L303 basically, a storage device so you're not constantly recalculating that between beginning and end of frame
Q): ah 2 mat to go back and forth between coordinates
Q): or go from world to camera then from camera to the screen
A): when we hit that renderWorld(updateRect); is where it'll split up into one of 6 possibilities: editTSctrl, GameTSCtrl, GuiMaterialPreiview, GuiObjectView, GuiShapeEdPreiview, and guiTSctrl. should be self-evident from the names which override is relevant to which portion
Q): so everything is not updated together?
A): and no. edittsctrl for instance replaces the guitsctrl or gametsctrl, while guiobjectview, and guimateiralpreview are their own micro-scenes
A): no worries. it's a lot to digest
Q): okay...when you feel like you have hit an end to "a chapter" this book..can we stop for the day...getting a bit late for me
Q): in this book*
A): heh. ok, so we'll say void GameRenderWorld() to GFX->updateStates(); ie: https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/T3D/gameFunctions.cpp#L414 to https://github.com/GarageGames/Torque3D/blob/4716f76d5e1855c0672937da15c72001832b2c50/Engine/source/gfx/gfxDevice.cpp#L346 will be your 'homework' then. that's one example of where it starts getting down to the bare metal
we'll be picking up the rest come monday
11/14/2014 (3:38 pm)
pt9)A): so we left off at setDisplayTargetResolution. next significant bit is that's where she sets the GFX->setWorldMatrix( worldToCamera );, mSaveProjection = GFX->getProjectionMatrix(); etc so that during rendering it'll know where the camera needs to be in terms of trasnlation, rotation, Field of view etc in order to form a rendering frusutm (the bounds of the scene used to determine what all renders)
Q): that part i undertand...
Q): matrix fun...
A): PFXMGR->setFrameMatrices( mSaveModelview, mSaveProjection ); postfx subsystem hook. (paraphrasing) this is where it tells the screenspaced sized quads that are layered on top of everything relevant bits of data they'll need to know later as well
Q): what is frameMatrices never heard of them...but is it just multiplying the projection and the model view matrix?
A): https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/postFx/postEffectManager.cpp#L303 basically, a storage device so you're not constantly recalculating that between beginning and end of frame
Q): ah 2 mat to go back and forth between coordinates
Q): or go from world to camera then from camera to the screen
A): when we hit that renderWorld(updateRect); is where it'll split up into one of 6 possibilities: editTSctrl, GameTSCtrl, GuiMaterialPreiview, GuiObjectView, GuiShapeEdPreiview, and guiTSctrl. should be self-evident from the names which override is relevant to which portion
Q): so everything is not updated together?
A): and no. edittsctrl for instance replaces the guitsctrl or gametsctrl, while guiobjectview, and guimateiralpreview are their own micro-scenes
A): no worries. it's a lot to digest
Q): okay...when you feel like you have hit an end to "a chapter" this book..can we stop for the day...getting a bit late for me
Q): in this book*
A): heh. ok, so we'll say void GameRenderWorld() to GFX->updateStates(); ie: https://github.com/GarageGames/Torque3D/blob/69838bdc8c9bc055b9b1ae76f42b0f28d2a33909/Engine/source/T3D/gameFunctions.cpp#L414 to https://github.com/GarageGames/Torque3D/blob/4716f76d5e1855c0672937da15c72001832b2c50/Engine/source/gfx/gfxDevice.cpp#L346 will be your 'homework' then. that's one example of where it starts getting down to the bare metal
we'll be picking up the rest come monday
#13
11/16/2014 (11:05 pm)
Awesome info here :D. Thanks for posting this, it will help greatly. 
Azaezel
and
torque3d.wikidot.com/coder:extending-the-torque3d-material-system
go into precisely that.
To use github.com/Azaezel/Torque3D/commit/bea891a55c2fce4c060c27553ae9d0c7f0a4beec as an additional example:
1)In ShapeBase::prepBatchRender we grab the object-instance's health, and tie it to the TSRenderState
2)In TSMesh::innerRender we tie the TSRenderState to the MeshRenderInst
3)In RenderBinManager::setupSGData we pass info from the MeshRenderInst to a SceneData
4)In ProcessedShaderMaterial::setSceneInfo we bind the variable to a constant handle
5)In shaderGenVars.cpp wre bind our internal variable to a string.
6)In MYHACKYREVISEDFeatHLSL::processPix or ::processVert we look up that bound constant and tie it to shader code inserted into an automatically generated shader for usage.
A brand spanking new feature gets a bit more involved. Before we go there (at which point we'll turn to... https://github.com/GarageGames/Torque3D/pull/861 say) what portions of that need further clarification?