| Photos | Blog | Random Things | Links | Guest Book | Resume |
Engine ArchitectureDec 11, 2002Times are in EST Actual discussion starts about 19:08 [16:50] <RedBeard> you gonna be making a presentation? [16:52] <Exellon> hmm [16:52] <Exellon> well i got 2 hours dont i :) [16:53] <Exellon> i see if i can get something orderly worked up at least [16:53] * asdf gets the popcorn [16:53] <RedBeard> ok [16:54] <Exellon> not like im an expert on software engineering or anything [16:54] <Exellon> and irc doesnt give you much to present with anyhow :) [16:54] <RedBeard> true [16:54] <asdf> if only irc had a whiteboard [16:54] <RedBeard> i've seen a java applet whiteboad before [16:54] <Exellon> theres always frantic DCCing [16:55] <Exellon> RedBeard: think you might be able to find it? [16:55] <RedBeard> i'm considering presenting some stuff on my t-portal things, but i haven't completed them yet [16:55] <asdf> what's a t-portal? [16:56] <Exellon> oh btw whats the timeframe :) [16:57] <RedBeard> whatever [16:57] <Exellon> alright [16:57] <RedBeard> 5 minutes, half an hour [17:15] <RedBeard> so.. anybody got ideas? [17:16] <Exellon> i thought we might kick it off by describing some *major* modules [17:16] <RedBeard> such as? [17:16] <Exellon> Kernel, Graphics, Sound, input, Network, Console, Scripting, Game [17:16] <Exellon> AI [17:16] <Exellon> Terrain [17:17] <Exellon> Physics [17:17] <RedBeard> hmm ok [17:17] <Exellon> all at a very high level of course, as we wouldnt have time to delve in any farther [17:17] <RedBeard> not tonight at least [17:18] <Exellon> i was going to try to focus things mainly on the graphics engine [17:18] <Exellon> ways to make things easier to use and stuff (eg. render queues, etc.) [17:19] * Quits: Washu (direwolf@adsl-64-161-26-45.dsl.sntc01.pacbell.net) (Ping timeout for Washu[adsl-64-161-26-45.dsl.sntc01.pacbell.net]) [17:21] <RedBeard> ok [17:38] <Exellon> anything else we might be interested in discussing, or do you think the other stuff will take most of the time? [17:39] <RedBeard> not sure really [17:39] <RedBeard> perhaps talk about an OO approach to things [17:39] <Exellon> yea [17:39] <Exellon> i was planning on that ;) [17:59] <Exellon> t minues one hour remaining [18:01] <RedBeard> heh yep [18:02] <RedBeard> feel free to invite more people in a lil while [18:02] <RedBeard> just don't go spamming the channel all over the place [18:03] * Exellon is now known as Exellon|bathroom [18:03] <Exellon|bathroom> aight will do [18:10] * Quits: asdf (asdf@pc-62-31-81-155-ll.blueyonder.co.uk) (Read error to asdf[pc-62-31-81-155-ll.blueyonder.co.uk]: Connection reset by peer) [18:10] * Joins: asdf (asdf@pc-62-31-81-155-ll.blueyonder.co.uk) [18:12] * Exellon|bathroom is now known as Exellon [18:29] <RedBeard> i need some dinner [18:29] <RedBeard> bbiaf [18:29] * Joins: Washu (direwolf@adsl-64-170-155-216.dsl.sntc01.pacbell.net) [18:29] <Washu> I LIVE [18:29] * Washu drops dead [18:36] <Exellon> i r teh returned [18:41] * Joins: nuvem (StormWind@dhcp-36.res.auc.ca) [18:42] <Exellon> welcome nuvem [18:43] * Joins: Misato (direwolf@adsl-64-170-153-208.dsl.sntc01.pacbell.net) [18:43] * Quits: Washu (direwolf@adsl-64-170-155-216.dsl.sntc01.pacbell.net) (Ping timeout for Washu[adsl-64-170-155-216.dsl.sntc01.pacbell.net]) [18:44] * Misato is now known as Washu [18:48] * Joins: psykotic (vognsen@3E6B2AFB.aarh.stofanet.dk) [18:49] <Exellon> 15 minutes :) [18:52] <Exellon> .invite Cell [18:56] <Exellon> u back yet Red? [19:00] <RedBeard> yeah [19:01] <RedBeard> btw, i am making an engine, wouldnt say i've "made one" yet though [19:01] <Exellon> so am i [19:01] <RedBeard> i would think that mine is slightly more advanced at this time [19:01] <Exellon> than mine? yes it is [19:02] <Exellon> yours can er..... put little 3D pixels and line segments on the screen........ what would that be called.... rendering, yea....... mine cant [19:02] <RedBeard> (this was mentioned in regards to the comments in #flipcode) [19:03] <asdf> /\ [19:04] <Exellon> ah crap we need masterg [19:04] <RedBeard> well he's not around right now [19:05] <Exellon> o wellt ehn [19:06] <RedBeard> alright, care to beging with a little something? [19:06] <Exellon> sure [19:07] <RedBeard> have you made the people in #gamedev aware of this? [19:07] <Exellon> once [19:07] <RedBeard> eh ok [19:07] <RedBeard> .v Exellon [19:07] * X2 sets mode: +v Exellon [19:07] <RedBeard> .set mode +mnt [19:07] * X2 sets mode: +m [19:07] * Joins: Second_Strike (Second_Str@dhcp-80c-1185.unm.edu) [19:08] <RedBeard> msg an op if you have something to add to discussion [19:09] <Exellon> alright, i guess we could start out by outlineing the in's and out's of each major module in an engine [19:09] * Joins: synapse|away (synapse@alb-24-195-25-41.nycap.rr.com) [19:09] <Exellon> - Kernel [19:09] <Exellon> - Graphics [19:09] <Exellon> - Sound [19:09] <Exellon> - Input [19:09] <Exellon> - Network [19:09] <Exellon> - Console [19:09] <Exellon> - Script [19:09] <Exellon> - Game [19:09] <Exellon> i probably missed a few there [19:10] <RedBeard> well, to begin with: engine architecture. it seems that these days, a game cannot be made "from scratch" in a reasonable amount of time, so we've taken to building somewhat-generic "engines" that can do the grunt work, leaving the application/game programmer to do more important things [19:10] <RedBeard> so that's the basic topic of discussion. how deep the "engine" parts go can vary from one to another - some provide advanced things like scripting and abstract game interfaces. some games are in themselves a complex engine with just some content plugged in [19:11] <Exellon> one of the problems these days though is that the general development crowd doesnt know how to properly structure their engines, resulting in messy, hard-to-debug code, and more headaches [19:11] <RedBeard> as Exellon pointed out, an engine is usually composed of several modules that focus on different aspects of what will be handled [19:12] <Exellon> certain games may not require a complete module for their aspects [19:12] <Exellon> the input module could very well be integrated with the Kernel [19:12] <RedBeard> i'm sure most people have heard of "code reuse" and "polymorphism" and things like that in relation to object-oriented code, and an engine is a great example of such functionality. It's a general rule of thumb that a good engine is object-oriented, so that each of the modules is segmented properly [19:13] <RedBeard> we probably won't go into a ton of detail with the object-oriented paradigm, but the general idea is that an object-oriented design is a Good Thing(tm) [19:13] <RedBeard> so, i'll let Exellon talk about his stuff [19:14] <Exellon> well, there are several specific modules i wanted to focus on tonight [19:14] <Exellon> namely, the Kernel, Graphics, Console, and Scripting [19:15] <RedBeard> oh, and i'll mention that after we discuss things, we'll take off the +m and let people discuss - also note that you can msg an op (me) if you have some input [19:15] <Exellon> in a large-scale game, the console and scripting systems are often tightly integrated with the rest of the modules [19:15] <Exellon> a good component model would come in very handy in such a game where each modules functions may also need to be accessed from the console and scripting systems [19:17] <Exellon> on another note, consistency in naming and organization throughout the engine is very important, especially in larger games [19:18] <Exellon> any input on what ive put forth so far? [19:18] <RedBeard> (C++'s namespaces can also aid in that, by keeping you from cluttering up the global namespace with your identifiers) [19:19] <Exellon> yea, you can probably see the obvious application of namespaces in concurrency with the module paradigm [19:20] <Exellon> my engine that i'm currently working on is in its early stages, and i have yet to devise a way to integrate the console and scripting systems throughout its framwork [19:21] <RedBeard> in my experience, the "console" usually doesnt add much functionality to an engine until you have a decent amount of variables and content available inside the engine - and that's usually game stuff more than engine stuff [19:22] <Exellon> very true for certain types of console systems, such as Quakes, where the general variable handling is rather simple [19:23] <Exellon> a more advanced console might specify abstract base classes such as IConsoleVariableHandler or IConsoleCommandHandler to be implemented by the appropriate modules/classes [19:24] * Joins: masterg (~asdfid@ip68-8-22-175.sd.sd.cox.net) [19:24] * X2 sets mode: +o masterg [19:24] <Exellon> ill be right back, Red why dont you unmoderate it for a few minutes eh? [19:24] <RedBeard> .set mode -m+nt [19:24] * X2 sets mode: -m [19:25] <RedBeard> anybody have something to add so far? [19:26] * nuvem does, but has to split for a few [19:26] <RedBeard> quick blurt? [19:27] <Washu> Scripting by using a premade language (python, Ruby, etc) is probably a better idea than reinventing the wheel [19:27] <RedBeard> very true [19:28] <RedBeard> and implementing your console to interface that scripting language would also be a good idea, so that you could do script commands in the console or from pre-made files [19:28] <Exellon> and considering many languages have embedding packages that come with them also [19:28] <Washu> and I believe that integrating Exellon's console with such a language would prove to be a very powerfull tool (runtime scripting) [19:28] <Exellon> i havent worked out all the eh **cough**kinks**cough** in that system yet [19:29] <RedBeard> ultimately you'd like to have your game run itself without need for a console, but for doing quick checks and modifications while running without needing a recompile, it can be useful [19:29] <Washu> or runtime debugging, want to check out an AI idea you just had, code it up while the game is running and have it execute it then and there [19:30] <Washu> It also makes incorporating your engine into an editor much easier [19:31] <masterg> washu: im not sure where youre going with that idea; could you expand? [19:31] <Exellon> it seems as though such a large engine as the one we're discussing here might require a more specialized scripting language [19:32] <RedBeard> oh i dunno... python, small, and ruby all seem to have good ways to have the script interact with underlying machine code [19:32] <Washu> sure: If you have a scripting language, its generaly executed at runtime, thus there is no need for the scripts to be static, and if you integrate it with an editor, the editor can alter them on the fly and you could view the results in a window that is part of the editor [19:32] <Washu> also, Python and ruby allow you to add extensible modules to them fairly seamlessly [19:32] <Washu> infact, Ruby and C/C++ Code can execute almost interchangeably [19:33] <Exellon> isnt Python used in more than a few games already? [19:33] <Washu> Stackless Python is another good alternative [19:33] <Washu> yes, Python is used in several games (stackless python is used in Eve-Online_ [19:34] <Washu> As you can imagine, intermixing C/C++ code and a scripting language gives you flexibility, and speed [19:35] <RedBeard> let me steer the discussion a little... [19:35] * Washu lets go of the ruder [19:35] <RedBeard> scripting is definitely Good Stuff(tm), but it's not much use without some underlying things to script and control [19:36] <RedBeard> so let's drop down to a slightly lower level and talk about how things are represented visually to the user - graphics and related topics [19:36] <Exellon> we all know theres a million ways to organize a graphics engine [19:36] <Exellon> scene graphs are an excellent way to help things get organized [19:36] * Joins: nuvem2 (jirc@hawk-dmz-if.auc.ca) [19:37] <RedBeard> many things fall into the topic of "scenegraph" [19:37] <Washu> Should it not be all game objects? [19:37] <RedBeard> spatial partitioning techniques are pretty much the core of a scenegraph though [19:37] <Exellon> well lets discuss those a little bit [19:37] <Exellon> i believe RedBeard is probably a lot more experienced with that field than i am however [19:38] <RedBeard> as far as graphics are concerned, you want to be able to draw only the relevant information at a given time [19:38] <RedBeard> i'm sure everybody's heard of and perhaps used or even made a BSP tree - the magic behind quake1 and many other engines since [19:39] <RedBeard> BSP works by recursively subdividing space into 2 pieces, such that when you know which side of the dividing line that you're on, you need not consider doing anything with the things on the other side - cases arise where you span the dividing line and have to consider both sets of data though, and the BSP can also help determine which data should be considered "first" [19:40] * Joins: mittens (narf@userd15.torchlake.com) [19:40] <RedBeard> .set mode +mnt [19:40] * X2 sets mode: +m [19:40] <RedBeard> .v Washu [19:40] * X2 sets mode: +v Washu [19:41] * Joins: terminate (terminate@dunk-01-099.dialup.netins.net) [19:41] <RedBeard> there are several variants on the BSP: some split space along the plane of some geometry in the world, some find an axis-oriented plane to divide things, some use complex metrics to determine a plitting plane [19:42] <RedBeard> but you can abstract the axis-aligned BSP up to more divisions, such that it divides space along multiple axes from the same point - that is what a quadtree and an octree do [19:43] <RedBeard> the most-well-known quadtree and octree implementations start with a square or cube that contains the entire data set, and then evenly subdivide into equally-sized squares and cubes (4 or 8 at a time, hence quad and oct) [19:44] <RedBeard> the method of subdivision is designed so that a minimal amount of data ends up being stored in the deepest nodes of the trees, so that when you go to look at them, you're actually saving computation time by not considering so many items [19:46] <RedBeard> these items can be polygons, primitives, objects, or whatever else you want to store into the tree - and they aren't limited to 3D applications. a quadtree is inhernetly a 2D structure, and a BSP can be used in pretty much any dimension, once you understand what the hyperplane in a certain dimension is doing (in 2D, it would be a line) [19:47] * Quits: synapse|away (synapse@alb-24-195-25-41.nycap.rr.com) (Signed off) [19:47] <RedBeard> there are other spatial subdivision techniques, but these are the most-often used - you can also do different types of trees that use abstract hierarchies of spheres, boxes, etc [19:48] <RedBeard> any serious questions? [19:49] <Washu> Yes: [19:49] <Washu> What are the advantages of using each? Quadtree, , Octree or, BSP [19:49] <RedBeard> ah yes [19:49] <RedBeard> well, there are several considerations in picking a data structure to use [19:50] <RedBeard> most of all, these are memory usage, speed of traversal, and speed of compilation [19:51] <RedBeard> a quadtree and octree tend to have a reasonably fast compilation time - O(n log n) - compared to BSP - O(n^2 log n) [19:51] <RedBeard> since the selection of the splitting plane in a BSP compiler is a rather complex and time-consuming task [19:51] <RedBeard> whereas the quadtree and octree use an even subdivision scheme - although you can apply a complex splitting metric to both of those also [19:53] <RedBeard> in terms of traversal efficiency - it depends on what kind of traversal you want to do. finding spatial adjacency in any of these usually requires a backtrack through the tree structure, unless you design in a (usually complex) adjacency scheme [19:53] * Quits: Second_Strike (Second_Str@dhcp-80c-1185.unm.edu) (Signed off) [19:54] <RedBeard> if you are just looking for a set of data that could possibly intersect a point, then it's fairly quick to look up things in an octree or quadtree because they subdivide the data faster [19:54] <Exellon> RedBeard: how about your BSP/Octree hybrid you were discussing the other night? [19:54] <RedBeard> heh that's a pretty complex approach, but the general idea is this: [19:55] <RedBeard> each "room" in the universe (assuming a subtractive geometry approach) is stored into a "universal octree" using its AABB (axis-aligned bounding box) [19:55] <RedBeard> so you can quickly find which room you are in given a "universal position" [19:56] <RedBeard> the rooms themselves can implement any kind of internal subdivision scheme to aid in collision detection within the "room" [19:56] <Exellon> well anyway, we may be straying from the general discussion topic a bit... [19:56] <RedBeard> where a "room" can be an actual room, a large piece of terrain, vast empty space, whatever [19:56] <RedBeard> ok, to make it more architecture-oriented: [19:57] <RedBeard> the scenegraph scheme uses one method of spatial subdivision at the universal level, so as to index the individual "pieces" of the universe [19:57] <RedBeard> then each piece or room can have its own internal routines for doing collision detection, visibility culling, etc [19:58] <Exellon> also, in my engine ive isolated the graphics and terrain engines from each other [19:58] <RedBeard> this kind of approach lends itself well to a polymorphic object paradigm [19:58] <Washu> What about culling problems that crop up for each (type of geometry (buildings vs terrain vs space)) and other problems (items spanning multiple nodes)? [19:58] <RedBeard> heh ok [19:59] <RedBeard> concerning objects spanning nodes: there are several approaches to deal with a spanning object (where "spanning" means it's inside more than one subdivided node) [20:00] <RedBeard> BSP trees, which have generally been used to split up geometry on a per-polygon level, tend to either A) split polygons along the splitting plane if it exists on both sides of the plane, or B) put the polygon into the lists of polygons on both sides [20:01] <RedBeard> splitting the polygon is beneficial to rendering schemes, because you can traverse the tree from front to back and be guaranteed that each polygon you encounter will only render the pixels on that side of the plane [20:01] <RedBeard> retaining the whole polygon in both lists is beneficial for compilation time and memory efficiency, since you don't need to split the polygon or store duplicates of the geometry - the lists on each side can just store a reference to hte actual polygon [20:02] <RedBeard> in a quadtree or octree, the basic approach is the same, except some things can't really be split like that [20:02] * Joins: MachinShin (whoIZthis@user-0c8gmg2.cable.mindspring.com) [20:02] <RedBeard> for instance, if a car is in 2 child nodes of a quadtree, then you don [20:02] <RedBeard> don't want to slice it in half and put each half in one node [20:03] * Joins: qDot (qDot@ip68-97-3-117.ok.ok.cox.net) [20:03] <RedBeard> so you can instead just put a reference to the object into each of the nodes that it's in, or store it in the "smallest spanning node" - the smallest node that wholly contains the object [20:04] <RedBeard> using the spanning node method can good on memory efficiency and tree depth, but ruinous to traversal speed - you have to consider objects that might not even be in the leaf node that matches your position, because the object exists in a parent node (spanning node) [20:05] * Joins: randal (randal@c68.117.135.143.mad.wi.charter.com) [20:06] <RedBeard> one workaround proposed for that is the concept of "loose quad/octtrees" which makes the seam between nodes less distinct, allowing you to store an object into only one node even though it actually is in more than one [20:06] <RedBeard> you can look at an article on that in one of the game programming gems books, and perhaps online too [20:06] <Exellon> has anyone ever considered the usage of a "render queue" concept? [20:07] <Exellon> such as is used in OGRE [20:07] <RedBeard> so once you have these subdivision methods down, you have your geometry stored in them, and you have a method of culling the objects so taht you're considering a minimal set for rendering/collision/whatever... then you want to render them! [20:08] <RedBeard> i'm not sure about a "render queue" but i;ve seen various techniques for sorting objects to be rendered, based on the renderstates that they need to use [20:09] <RedBeard> because hardware works best when you don't change all the states between rendering objects, it's optimal to arrange your objects to minimize expensive state changes (render target is worst, then applied textures and shaders, then things like materials, lights, etc) [20:11] <RedBeard> you can implement this arrangement using some sorting scheme - can do a quick arrangment of things that all use the same texture by sorting items together that store the same texture pointer (since the pointer is unique on the system while the object isn't destroyed) [20:11] <Washu> This is where managers come in. [20:11] <RedBeard> the level of abstraction applied to that sorting scheme kind of depends on how detailed your renderstates are [20:12] <RedBeard> also, doing a dynamic sort (where the expense of certain renderstate changes are different on various hardware) i think is an NP-complete problem, not sure though [20:12] <Washu> perhaps using some form of a static metric along with hardware cost [20:13] <RedBeard> yeah you can fake it and generalize, adjust order-of-importance and things [20:14] <RedBeard> but it can get nasty when doing things like texture blending, where only certain textures need color applied, the color buffer must be kept intact, etc - dx9's multiple rendertargets might help to alleviate some of the pressure there [20:16] <RedBeard> are there more topics within graphics that people would be interested in discussing? [20:16] <RedBeard> .set mode -m+nt [20:16] * X2 sets mode: -m [20:17] <nuvem2> You have to watch the amount of processing you put into sorting [20:17] <nuvem2> you can end up adding more overhead than the texture switch you're trying to avoid [20:19] <RedBeard> possibly... it seems that most applications are still CPU-limited even with massively powerful GPU's, so that is a valid concenr [20:19] <nuvem2> Also, assuming you're an indie developer, the time put into a good sorting system may not be worth it [20:19] <Exellon> processor-specific optimization [20:20] <nuvem2> one has to question the gains over a simple bucket sort by material [20:20] <Exellon> with MSVC++'s processor pack you can optimize for SSE, SSE2, MMX, AMD, and Intel [20:21] * Quits: qDot (qDot@ip68-97-3-117.ok.ok.cox.net) [20:22] <RedBeard> nuvem2: the approach that i've implemented for doing the renderstate sorting is this: i made a templated BST that can sort based on N DWORD inputs, and i put the pointers to each of the material attributes, in order of importance, into those DWORD slots [20:22] <RedBeard> then the BST sorts, sorting all the most-expensive states together, and within those states, the next-most-expensive state changes [20:22] <RedBeard> and so on [20:23] <RedBeard> you can change the sorting scheme to a radix sort, which works quite nicely on unsigned integers such as pointers [20:24] <RedBeard> and add some bucket-sort fallbacks in that if you so desire [20:25] <RedBeard> admittedly, i haven't tested my scheme with a large dataset yet, but i don't see any inherent weaknesses to doing a fairly painless sort before invoking tons of state changes [20:26] <nuvem2> sounds good to me [20:26] <nuvem2> aside from state changes, the only other major concern is never touching your vertex data [20:27] <RedBeard> ah yes - if you can avoid it [20:27] <RedBeard> one optimization that you can try there is a multi-stream model and only upload streams that have been modified [20:27] <Washu> which you can with the majority of your data [20:28] <Washu> except for somethings, like animated objects [20:28] <RedBeard> so if your texture coordinates stay the same but your positions are moving (animated skin mesh) then you only need update the positions [20:28] <nuvem2> streams aren't friendly to the cache though [20:28] <nuvem2> at least not on the newer ATi cards [20:28] <RedBeard> but for the most part, leaving the data alone once it's on the card is a Good Thing(tm) - XBox excluded [20:29] <RedBeard> i think ATi just plain doesnt like streams for some reason [20:29] <nuvem2> Washu: actually, most animated objects can remain untouched if you have shader support [20:29] <nuvem2> Red: I doubt it [20:29] <RedBeard> their cards only support 8 (nvidia does 16) and now this... [20:30] <nuvem2> I could understand how it would mess with the vertex cache [20:30] <RedBeard> i don't really see how [20:30] <RedBeard> vertex cache is based solely on indexing [20:30] <RedBeard> use index buffers, it caches your vertices (and it can put em into the cache however it wants) [20:30] <RedBeard> then when it comes across the same index, it can just grab that vertex again from the cache [20:31] <nuvem2> except if that data has changed [20:31] <RedBeard> if it's changed, it's not the same vertex [20:31] <RedBeard> there might be a memory-cache hit from having to access different parts of memory for the various streams, but i'm not sure how big of an "L2" cache video cards have [20:32] <nuvem2> that's probably the issue, if anything [20:32] <RedBeard> if your data is static then you can put it into interleaved (FVF) format [20:33] * nuvem2 had a brainfart there with the data has changed bit, so excuse him [20:33] <Washu> ok, I think we need to move on a bit though, we are getting to specific [20:33] <RedBeard> because you won't be changing any of it - the streams optimization was for data that is dynamic [20:33] <RedBeard> fair enough [20:34] <nuvem2> In any case, ATi has said to avoid streams on their new cards... we'll just have to see what NV says about the issue to know if it's vendor-specific [20:34] <Washu> Were getting down to the programming side, and that can be argued for years, I would rather see idea's and theories on the current topic (Engine Architecture, more specificaly, scene graphs and object management) [20:34] <Washu> *we're [20:34] <RedBeard> alright [20:35] <RedBeard> well i've talked about spatial subdivision [20:35] <RedBeard> i think i covered most of the relevant topics there [20:35] <Washu> yes, you did... [20:35] <Exellon> a simple component model would be good to facilitate the engine in general [20:35] * masterg is now known as masterg|phone [20:35] <Washu> you did miss a few things, like when to use a bsp over a quad over an oct [20:36] <Washu> Hierarchical objects using inherited policies is one way to manage objects [20:37] <RedBeard> well, based on the speed efficiency for various things, i'd generally say that a BSP is best used on static data, and quadtrees on things like terrain [20:38] <RedBeard> there's another interesting application of an octree regarding color palettizing of a bitmap - you treat the axes as RGB values and store a pixel count of each color into a node - once you're done, you build a palette based on the most-populous nodes [20:38] <Washu> hrm, I had not thought of that [20:38] <RedBeard> you could generalize that concept to other data that works on multiple "axes" [20:40] <MachinShin> that sounds like huffman coding to me [20:40] <RedBeard> it might be, i'm not terribly familir with that algorithm [20:42] * Quits: nuvem2 (jirc@hawk-dmz-if.auc.ca) (Leaving) [20:43] <Washu> ok, what kind of a tree would you use for storing objects? [20:43] <Washu> not geometry [20:43] <RedBeard> what kind of objects? [20:43] <Exellon> alright.... back to archietcture... how about a different aspect of the graphics core, such as the entity subsystem and meshes [20:43] <RedBeard> static ones, moving ones, big ones, small ones? [20:43] <Washu> but the acctual objects (code, data (including geometry), etc) [20:44] <RedBeard> hmm, in my current scenegraph there really isn't too much in the way of "objects" that aren't represented spatially [20:46] <Washu> how do you do things like AI and such then? [20:46] <RedBeard> in what respect? [20:46] <RedBeard> AI is a very broad topic... pathfinding perhaps? [20:47] <Washu> ok, I have a character, the character has a gun, the gun has a clip, the clip has bullets how do you store that in your scenegraph? [20:47] <Exellon> generate the bullet shells dynamically to eject from the gun when needed [20:47] <Washu> well, that's just an example [20:47] <Exellon> just store the ejection point not the bullets [20:48] <Washu> but its a good one where you have a parent child relationship [20:48] <RedBeard> true [20:48] <Washu> how does character tell gun to fire, which then asks the clip if its empty, and if not to loose bullets [20:48] <Exellon> an Action class [20:49] <RedBeard> generally i'd consider that a scripting or game code issue rather than an engien issue [20:49] <Washu> and how do you store that in your scenegraph so that they know who their parent is? [20:49] <Exellon> passes on to a GunService class, which in turn queries the Gun object for an empty boolean [20:49] <RedBeard> if you can consider the gun and the character to be one "thing" - they aren't really separate - then you could just either consider the gun part of the character or create a composite object composed of gun & character [20:49] <Exellon> i wouldnt store it necessarily in the scenegraph [20:49] <Washu> red: but the character could have multiple guns, or none at all... [20:49] <Exellon> just for rendering purposes [20:49] <nuvem> I would agree with RedBeard on this one, it's definitely a scripting/game issue [20:50] <RedBeard> i'd say this is the case where the "scenegraph" isn't the same thing as an "object graph" [20:50] <nuvem> The scenegraph is merely for spacial partitioning of the renderered scenes [20:50] <Exellon> very true [20:50] <Washu> not really, if your engine doesn't have some way to store and manipulate the objects in some way, then its not really complete. and most articles and books that I have scene treat scenegraphs as more than just a geometry object [20:51] <Washu> but as the "Scene Graph" or a tree that stores the objects in the scene [20:51] <nuvem> Well, I disagree with that use :) [20:51] <Washu> a "Geometry Graph" is something else, and generaly a major member of the Scene Graph [20:51] <RedBeard> true, and as i said, i would consider a method of compositing the objects into one object, and that representation would be an "object graph" and the composite would be a single entry in the "scene graph" [20:52] <nuvem> IMO, game objects can be better represented by the game code itself [20:52] <Washu> nuvem: The scene graph is represented by the code [20:53] <RedBeard> my concept of abstracing the actual geometry graph out also falls into this area - the "rooms" in my scenegraph define their own visibility and collision methods [20:53] <RedBeard> and the scenegraph merely coordinates their actions, querying for the geometry, the collision, etc, based on a generalized input [20:53] <Washu> so the scene graph ends up being a general database to store anything...as it should [20:53] <nuvem> should? [20:53] <RedBeard> right, and it doesn't go into utmost detail about how to store the individual things that get put into the scenegraph - it leaves those to sub-graphs [20:54] <Exellon> i think that the scene graph should be isolated from the object graph... considering they would be in two different modules [20:54] <Washu> a scene graph should represent the entire "Scene" hence it should know everything, and thus store everything in the scene [20:54] <Washu> Red: there, that's what I wanted. [20:54] <Exellon> it should have direct access to the object graph [20:54] <Exellon> but not total control [20:54] <RedBeard> it does indirectly index everything, but making use of a polymorphic object scheme, it only needs and abstract interface to give and receive those queries [20:55] <RedBeard> for example, do you really want your scenegraph to keep track of all the wheels on your car? [20:56] <Washu> no, but I would want it to know that there is a car [20:56] <RedBeard> in a general sense, that information is "in" the scenegraph, but it's not really being stored in the scene itself - they are sub-objects of a car, which is in the scene [20:56] <nuvem> Using the scenegraph to store everything results in a less than optimal representation [20:57] <Washu> nuvem: what then would you sugest gets stored there? [20:57] <Exellon> just rendering information , as is intended [20:58] <Washu> no, that's not the job of the scene graph [20:58] <Exellon> the scene graph and the object graph should be directly connected to each other [20:58] <RedBeard> my current approach is this: i have SceneNodes, which are the "rooms" in the scenegraph - they can do whatever they like internally: room in a building, rolling hills, spaceship, whatever. then i have SceneObjects, which are "things" in a general sense that are represented spacially with a bounding volume and some polymorphic subclassing [20:59] * Joins: pseudo (~screw@ACAD30BE.ipt.aol.com) [20:59] <RedBeard> does that kind of clarify my stance on things? [20:59] <Washu> Red: yes [20:59] <RedBeard> no actual geometry or specific sub-objects are directly stored in the scene, just general containers [20:59] <Washu> how do you deal with things that have no spacial representation [21:00] <RedBeard> such as? [21:00] <nuvem> Washu: those need not be in the scene graph, and thus can be stored in whatever fashion you wish [21:00] <Washu> I can't think of any off the top of my head, but I'm sure that there are some [21:00] <RedBeard> if you mean thing like AI scripts, those can be stored elsewhere and accessed by the things that need them [21:01] <Washu> nuvem: notice though, he's not storing geometry in the scene graph, just spacial objects, that could be anything from a sound to a geometric object [21:01] <RedBeard> since basically the engine is responsible for handling things like geometry - AI is usually very specific to a game - i wouldn't expect to include the AI and things like that in the scenegraph [21:01] <Washu> no, and AI would be scripted most likely anyways [21:01] <RedBeard> now take notice though, you could store things like pathfinding nodes through the SceneObject interface [21:02] <nuvem> Washu: I should clarify my stance: I'm not saying non-rendering information can't be stored [21:02] * Joins: blip (~asdf@co-ratlsnk-u1-c5c-221.clspco.adelphia.net) [21:02] <RedBeard> in that case, they don't really exist in a spatial sense (no volume or geometry), but they have position [21:02] <nuvem> physics information is quite viable for inclusion (ie. convex hulls), and so is sound that you mention it [21:03] <nuvem> well, sound emitters anyway [21:03] <Washu> now, when I think scene graph I think of a tree of generic objects that can then become more specific as they are traversed. Each object though deals with its own children (if it has any) and thus an object could have something specific under it, but the scenegraph wouldn't have to know anything about it [21:04] <nuvem> But game information: like the character/gun example, need not be included [21:04] <RedBeard> right, that's what i was saying [21:04] <Washu> so when I think of sticking things in the scenegraph, that means a node and its children, including the car example [21:04] <Washu> even if the scenegraph itself doesn't know it [21:05] <Washu> why wouldn't you include the character/gun example? [21:05] <Washu> does not he need to be rendered? [21:05] <nuvem> he does [21:05] <Washu> and collision detected [21:06] <Washu> now, he may not be a direct child of the scene graph, but he would be in there somewhere (from me definition) [21:06] <nuvem> but that would be all the scene graph need include: the meshes to render, and their positions in space (+ collision meshes if necessary) [21:06] <Washu> and he would deal with the colision detection himself, and ai if needed, but the scene graph would none the less include him [21:07] <nuvem> my point is the scene graph need not know it's a character or a gun [21:08] <Washu> no, it would just know that it exists, it would let the character determine what it is [21:09] <Washu> and that's what I'm saying, the scene graph shouldn't just store geometry information, it should have the "Scene" (all inclusive) in it. [21:09] * Joins: grok (someone@bb-203-125-108-4.singnet.com.sg) [21:10] <Washu> now, on to something new and exciting... [21:10] <Washu> Dealing with user input [21:11] <Washu> if you generalize it, then you can have AI, Networking, and the Local User all apear as the same thing. [21:12] <Washu> in a sense, all they do is say: "Move" and "Shoot" [21:13] <Washu> each does it differently though, the local use would use the keyboard/mouse to input their decisions, the AI would use state information of some sort to decide, and network would depend on a remote user (which could be AI again) but would be the new positions of the players, and their current state. [21:14] <Washu> the basic premiss however is that each has a chunk of information, generaly a new position and/or state information for an "object" in the game [21:14] <Washu> agreed? [21:16] <RedBeard> ok - so it's essentially a command/info pairing? [21:16] <Washu> basicaly [21:18] <Washu> I press the up arrow, the input message says to my character move forward, that then gets sent to the server I'm connected to as a new movement vector, which updates my remote character [21:18] <Washu> of course, that's not counting things like the server checking for a valid movement vector, and such [21:18] <RedBeard> (and the server can optionally send back a command saying "here's where you are, and where all the other people see you") [21:19] <RedBeard> which in network games is generally what causes "warping" [21:19] * masterg|phone is now known as masterg [21:19] <RedBeard> that's just a little implementatin blurb though [21:19] <Washu> unless you have some form of lag prediction, yes [21:19] * Quits: pseudo (~screw@ACAD30BE.ipt.aol.com) (throw new OutOfMemoryException;) [21:20] * Joins: mittens[smeep] (narf@userd15.torchlake.com) [21:20] * X2 changes topic to 'Upcoming lectures: Engine Architecture - Dec 11, 7pm EST | Contact an operator to schedule a lecture' [21:20] * Quits: mittens (narf@userd15.torchlake.com) (Read error to mittens[userd15.torchlake.com]: No route to host) [21:20] <Washu> but in either case, these messages, both user input, and network ones can be interpreted as input, which would let you have a single interface for updating all of your characters [21:20] <Washu> *objects [21:21] <Washu> along with AI and such, and lag prediction can be considered a form of AI [21:21] <masterg> how would you grant access to the input "system"/handler [21:21] <Washu> a generic interface most likely [21:22] <masterg> would you contain all possible input "checks" in one sole location? [21:22] <Washu> well, that would really be up to the coder [21:22] * mittens[smeep] is now known as mittens[mooooovie] [21:22] <Washu> I would rather have each object own its own input channel, and have them check when their tick hits [21:23] <nuvem> wouldn't that clutter object with input processing? [21:23] <nuvem> *objects [21:23] <masterg> in my past projects, i've preferred rather than looking into the corresponding input's "object" that specifically relates to it, having simply one area to reference to [21:25] <Washu> nuvem: yes, each object that required input would end up with their own input channel, which could end up cluttered, but thats why you use inheritance. [21:26] <Washu> and a child object wouldn't require an input channel unless it could move independantly of the parent [21:27] <Washu> and your going to end up with some form of input handling in those objects anyways, even if it is just messages. [21:27] <Washu> because anything that moves has to have a way to be told to move. [21:31] * Joins: Syntacs[Away] (Taff@adsl-18-246-63.gnv.bellsouth.net) [21:33] * nuvem just translates inputs into the proper function calls [21:34] <RedBeard> the input concept can be paired with "action mapping" and the scripting systems [21:36] <Washu> true [21:38] * X2 sets mode: -v Washu [21:38] * Joins: dimwit_fig (fig@rl-sac59034.reslink.csus.edu) [21:39] <dimwit_fig> lecturing on engine dev? [21:39] <RedBeard> so... anybody have something to add? [21:39] <dimwit_fig> can you repeat the whole thing just for me [21:39] <RedBeard> that's a negatory [21:39] <Washu> hahahaha [21:40] <dimwit_fig> right, nobody cares about poor little dimwit [21:40] <Washu> fig: that would be one long paste [21:41] * Quits: Washu (direwolf@adsl-64-170-153-208.dsl.sntc01.pacbell.net) (Read error to Washu[adsl-64-170-153-208.dsl.sntc01.pacbell.net]: Connection reset by peer) [21:41] <dimwit_fig> ahaha [21:41] <terminate> I bet someone could send you a log :P [21:41] <dimwit_fig> Washu's sending it [21:42] <RedBeard> ... and simultaneously d/c'ing it seems [21:42] <RedBeard> timing out, at least [21:42] <dimwit_fig> dcing [21:43] <nuvem> So what's next on the discussion list? [21:43] <Exellon> seems like we exhausted the graphics part of the engine [21:43] <RedBeard> it seems we've roughly covered most of the relevant topics... anybody want to go into more detail on something? [21:44] <grok> you guys already done the AI part? [21:44] * Quits: terminate (terminate@dunk-01-099.dialup.netins.net) (Ping timeout for terminate[dunk-01-099.dialup.netins.net]) [21:45] <RedBeard> haven't really covered much AI stuff [21:45] <RedBeard> since it's usually quite specific to different games and applications [21:45] * Joins: Washu (direwolf@adsl-64-170-153-208.dsl.sntc01.pacbell.net) [21:47] <RedBeard> if you'd like to discuss architecture aspects of AI things though, we could [21:47] <RedBeard> i personally haven't delved into many AI topics [21:47] <RedBeard> i'm more of a graphics nut [21:47] <grok> well i've been looking at trigger systems lately [21:47] <grok> it's a generalized part of any AI engine... [21:48] <RedBeard> ok, if you have some good information to present, i'm sure we'd all appreciate it [21:48] <grok> basically a messaging architecture for AI's to "interact" with the 3d world [21:49] <grok> well so far this is what i've gleaned fro my first game [21:49] <grok> your engine needs to support complex entity behaviour.... [21:49] <grok> any engine [21:50] <grok> like you make a monster attack, and on the fifth frame of animation, he fires off a projectile [21:50] <grok> it flies thru the air, hits another dude, which then goes into the a pain animation.... [21:51] <grok> now this stuff if you think about it is a PITA to code [21:51] <grok> er anyone with me on this? [21:51] <Washu> ok [21:52] <RedBeard> yeah [21:52] <grok> the easiet way to break this down is for your engine to provide some means for game entities to route this info to one another...efficiently... [21:52] <RedBeard> you don't want to have to do custom responses to collisions with various types of things (getting hit by rockets, bullets, etc) right... [21:53] <grok> and i'm still trying to find a nice way to tack such an event messaging system into a 3d engine.... [21:53] <grok> RedBeard: it's more the complex chain of events that follow... [21:53] * Joins: earthian (earthian@66.114.228.138) [21:53] <RedBeard> i see [21:53] <Exellon> subscriber/publisher system? [21:53] <grok> Exellon: like the java event model? [21:54] <grok> i originally wanted to do a signal/slots system... [21:55] <grok> but then i found much lighter free form solution.... [21:56] <grok> if you take a look AI Game Programming Wisdom, Jeff Orkin has an article on a general purpose trigger system [21:57] <grok> it provides several advantages over the publisher/subscriber model.... [21:57] <Exellon> i didnt get it from Java [21:57] <Exellon> i saw it in COM or COM+ or MTS, one of the three [21:57] <grok> Exellon: but it's similar in concept? [21:58] * Joins: EGreg (ace@DIAL7-ASYNC06.DIAL.NET.NYU.EDU) [21:58] <EGreg> hello :) [21:58] <Exellon> perhaps [21:58] <Exellon> i never delved into Java much [21:58] <EGreg> I would like to lecture on the engine architecture of aurora. YAY! :-) [21:58] <EGreg> hehehehe. [21:58] <RedBeard> hrmm [21:58] <RedBeard> .v grok [21:58] * X2 sets mode: +v grok [21:59] <RedBeard> .set mode +mnt [21:59] * X2 sets mode: +m [21:59] <RedBeard> in time :) [21:59] <grok> i believe the subscriber/publisher model is... [21:59] <grok> you subscribe to events your interested in and the publisher sends them to you... [21:59] <RedBeard> question from nuvem: [21:59] <RedBeard> <nuvem> grok: Can you give a quick summary of the general purpose trigger system? [22:00] <grok> ok basically the trigger system has an interface for any game entity to register a trigger [22:00] <grok> wtf!! [22:01] <grok> -EGreg- tell em about www.intermagix.com/aurora/code/Aurora.zip <-- it has events.h in it among other things ;-) [22:01] <grok> someone is noticing me.... [22:01] <grok> ok anyway [22:02] <grok> when you register a trigger with the trigger manager, you are saying that "Yo, i'm interested in this event" [22:02] <grok> ok now several things to consider about such a system is [22:02] <grok> 1) Priority - some trigger are more important than others... [22:03] <grok> 2) proximity - some triggers only affects objects within a certain distance from the source [22:03] <grok> 3) Expiration time - some trigger live for the duration of the game, others die out after sometime [22:04] <grok> so basically your entities can register trigger and remove triggers on themselves throughtout the game's simulation, depending on their internal logic [22:04] * Joins: nps (nps005@dsl-65-185-53-241.telocity.com) [22:04] * masterg is now known as masterg|dinner [22:04] * Quits: blip (~asdf@co-ratlsnk-u1-c5c-221.clspco.adelphia.net) (Ping timeout for blip[co-ratlsnk-u1-c5c-221.clspco.adelphia.net]) [22:04] <grok> nuvem: that answer your question? :) [22:04] <Exellon> nps u decided to come after all :) [22:06] <RedBeard> so for example, a guard might walk into a room and sit down at a computer, and would then be listening to messages from silent alarms in a base facility or something? [22:06] <Exellon> hey RedBeard: nps would like to be heard :) [22:06] <RedBeard> .v nps [22:06] * X2 sets mode: +v nps [22:06] <grok> RedBeard: yes [22:06] <nps> score [22:06] <nps> thanks [22:07] <grok> RedBeard: and once the alarm goes off, he would delete that trigger, change state and maybe in the new state set triggers for sounds of footsteps or gunfire...etc [22:07] * Parts: nps (nps005@dsl-65-185-53-241.telocity.com) [22:07] <RedBeard> sounds like a nice way to handle dynamic triggers - how might you go about specifying what triggers you're actually attached to though? [22:07] <grok> so the trigger system is a general interface for you to provide complex behaviour in your engine :) [22:08] <grok> RedBeard: You would call the trigger manager [22:08] <Exellon> oh oh i saw this in a RenderMan ad in Game Developer [22:08] <RedBeard> because as the example demonstrates, "silent alarms" "footsteps" and "gunfire" aren't very general [22:08] <Exellon> hold on a sec [22:08] <grok> trigManager.RegisterTrigger( this, TRIG_ALARMS ); [22:08] <grok> then you would have TRIG_GUNFIRE... [22:09] <RedBeard> ok, so you'd have to have a set of triggers that are known beforehand? [22:09] <grok> yup [22:09] <RedBeard> it seems somewhat like the subscriber/publisher model in that respect then [22:09] <grok> the general part comes from it begin able to be applied to any game [22:09] <Exellon> blah [22:09] <RedBeard> since by registerting (subscribing) to a trigger, you are then listening to a specific thing, and certain actions and entities would emit (publish) certain triggers [22:09] <Exellon> too much to type [22:10] <grok> RedBeard: yes, but like i said you have to consider the 3 things i mentioned above [22:10] <grok> over a normal publisher/subcriber model... [22:11] <Exellon> www.renderware.com/renderwareai.html [22:11] <grok> the publisher has to make some intelligent decisions about who to publish what to... [22:11] <RedBeard> yeah, you have a few modifiers based on spatial, temporal, and importance values [22:11] <grok> RedBeard: right, the priority is important because some triggers are more important than others... [22:12] <RedBeard> you could possibly generalize it further by having just a "channel" for each trigger, and publishers would just broadcast, then you could have an intermediate layer for filtering the triggers out to the affected entities which will receive them, based on those modifiers [22:12] <RedBeard> and as far as "footsteps" "gunfire" etc... that could possibly be generalized to "strange noises" [22:13] <grok> RedBeard: there's also the question of frequency [22:13] <RedBeard> with varying levels of volume and aggression [22:13] <grok> RedBeard: not all entities should be triggered every frame... [22:13] <grok> RedBeard: so it has to be a selective broadcast [22:13] <grok> with regard to the last time it the entity was triggered... [22:14] <grok> Exellon: you got any comments on that renderware article? [22:14] * Joins: terminate (terminate@dunk-01-056.dialup.netins.net) [22:14] <RedBeard> right, but i was saying that the publisher doesnt really care who receives - it just broadcasts at its location, perhaps with a specific insistency (priority) [22:14] <grok> ah yes [22:14] <grok> i think we should break it down to 3 parts to be more accurate [22:14] <grok> the publisher, the subscriber and the intelligent delivery man :) [22:15] * Joins: Badman (Badman@cs6625134-231.austin.rr.com) [22:15] <RedBeard> right, where the "delivery man" is the filter layer i mentioned [22:16] <grok> correct [22:16] <RedBeard> that would be the real meat of the system, i would guess [22:16] <grok> it is [22:16] <RedBeard> since the objects themselves would have to define their own actions and states based on their subscribed triggers [22:16] <grok> and to reiterate the filter needs to route based on priority, time and space [22:16] * Joins: Nutter (hehe@d141-243-8.home.cgocable.net) [22:16] <grok> RedBeard: yup [22:17] <grok> well that's about all i got to contribute about trigger system [22:17] <grok> they give a lot of bang for the buck [22:18] <RedBeard> here's the AI whitepaper Exellon pointed at: www.renderware.com/sales_sheets/abstract_ai_white_paper.pdf [22:18] <grok> despite being relative simple [22:18] <RedBeard> integrated into renderware apparently [22:18] <grok> This article is published in Dec 2002 GD Mag... [22:18] <RedBeard> i'd like to suggest that the idea of specific triggers could also be abstracted - i'm not entirely sure how, but instead of having constants it might be possible to have classes and subclasses of triggers [22:18] <grok> so don't waste your printer ink :) [22:19] <grok> er EGreg wanted you guys to see this link: [22:19] <grok> -EGreg- this might be relevant: www.flipcode.com/tpractice/issue06.shtml [22:20] <RedBeard> .v EGreg [22:20] * X2 sets mode: +v EGreg [22:20] <EGreg> hello [22:20] <RedBeard> grok - finished? [22:20] * masterg|dinner is now known as masterg [22:20] <grok> RedBeard: actually my next area of exploration is to see how best we can construct boolean based trigger conditions [22:20] <RedBeard> i mean with discussion :P [22:20] <grok> RedBeard: yup pretty much, if anyone has questions, just pm me :) [22:21] * Quits: Badman (Badman@cs6625134-231.austin.rr.com) (Signed off) [22:21] <EGreg> give me about 5 minutes, I want to do something. [22:21] <RedBeard> .devoice grok [22:21] * X2 sets mode: -v grok [22:21] <EGreg> actually 2 minutes is ok [22:22] <EGreg> I am going to talk about issues involved in designing an open ended scene rendering system. If anyone has questions, /msg me or RedBeard. I will start in about 2 minutes. [22:24] <RedBeard> .set mode -m+nt [22:24] * X2 sets mode: -m [22:24] * Joins: EGreg_ (egreg@DIALN-ASYNC490.DIAL.NET.NYU.EDU) [22:24] <RedBeard> anybody got something to say while we wait? [22:25] * Quits: EGreg (ace@DIAL7-ASYNC06.DIAL.NET.NYU.EDU) (Ping timeout for EGreg[DIAL7-ASYNC06.DIAL.NET.NYU.EDU]) [22:26] * Washu is now known as RandomGuy [22:26] * RandomGuy is now known as Washu [22:27] * Joins: mrfun (mrfun10@m119250.ap.plala.or.jp) [22:28] * mrfun takes a seat in the back of the hall [22:29] <Washu> omg, he interupted us and our moment of silence! [22:29] <Washu> ;) [22:29] * EGreg_ is now known as EGreg [22:30] <EGreg> I'll be starting in 2 minutes. Sorry for the delay. I am registering online for something :-) [22:31] <dimwit_fig> EGreg The Egregious! [22:31] <dimwit_fig> hehe [22:33] * Exellon runs out the back door to the bathroom, hoping he doesn't miss EGreg's speech [22:34] <dimwit_fig> lets hope his speech is not that short. heh [22:34] <RedBeard> .devoice Exellon [22:34] * X2 sets mode: -v Exellon [22:34] <dimwit_fig> why? [22:34] <Washu> because, lecturer doesn't want to be interupted [22:34] <dimwit_fig> but he haven't started yet [22:34] <RedBeard> .voice EGreg [22:34] * X2 sets mode: +v EGreg [22:35] <EGreg> Hello. [22:35] <Washu> bonjour [22:35] <Exellon> wie gehts [22:36] <EGreg> aloha [22:36] <dimwit_fig> privet [22:36] <EGreg> I am going to speak briefly about the kind of design model you can develop to be able to render completely different types of scenery , for example mix indoor BSP rendering with landscape rendering. [22:37] <RedBeard> .set mode +mnt [22:37] * X2 sets mode: +m [22:37] <EGreg> So far, I don't see enough of this in games. Quake II for example mainly uses BSP. [22:37] * Parts: earthian (earthian@66.114.228.138) [22:38] <EGreg> As hardware T&L has become standard, I see no reason for this. The BSP methods are good for a lot of things, don't get me wrong. But it would be nice to have a method of mixing various rendering techniques. let me give an example. [22:38] <EGreg> Suppose you want to render a room with chairs and other objects, and out the window you want to render a beautiful landscape, not one of those sky boxes that RTCWolfenstein has :) [22:39] <EGreg> The room is rendered in one way and the landscape is rendered in another way. In fact, they are not so hard to mix, if you place them in a portal engine. Here's why: [22:40] <EGreg> If you have a world with lots of different scenes and meshes which are rendered in lots of different ways, you can, of course, render all the meshes all the time. But this would be horribly inefficient. [22:40] * RedBeard would like to interject that the method he was discussing earlier, regarding SceneNodes and SceneObjects, is designed to handle this kind of thing, but i didn't go into much implementation detail [22:40] <EGreg> Instead, you can use a system that partititions the world into sections, each containing its own sector. [22:41] <EGreg> alright, then. I'll get to the point. Basically, you can code a simple portal engine to act as a container for all the separate sectors and meshes. [22:42] <EGreg> Treat the renderer like a state mchine. THe portal engine works great with this because you have a sort of "stack" with states. Rendering a sector through a portal is like a function call. Recursion is possible. At the beginning of a render, each sector has access to the current state. [22:43] <EGreg> The current state includes: the current transforms, the current clipping frustum, the relevant lights... each of these is a stack of its own basicaly. [22:44] <EGreg> This allows us to tell the sectors exactly the relevant info they need to render themselves. That's the trick - the sectors must draw themselves, through a virtual function interface, which is pretty simple to design (for example make Sector::Render(RenderInterface*)) [22:45] <EGreg> So, for example, the landscape would not have to render itself completely but only the part you see through the window. [22:45] <EGreg> I want to talk about some cool effects you can have with a portal engine and hardware T&L. [22:46] <EGreg> For example, in addition to the current frustum clipping the sector behind it, you can draw a transparent polygon to clear the zbuffer away so you can see through a wall. [22:46] <EGreg> This is good for real-time bulletholes and so on. [22:47] <EGreg> Imagine this scenario: you're outside, in a slandscape. You shoot through a wall in a building, and into a dark room light streams in through the hole. [22:47] <EGreg> There can be a few stock "hole in the wall" sectors, with portals to both sides of the wall. [22:47] <EGreg> Things like this are possible with a portal engine. Real time surface deformation, real-time perforation, real time lighting. And you can mix and match different rendering techniques. [22:47] <EGreg> I jsut want to see more of this. [22:48] <EGreg> Now I have to go for a while... you guys can discuss this :) [22:48] <RedBeard> .set mode -m+nt [22:48] * X2 sets mode: -m [22:48] <RedBeard> man, sounds exactly like my engine design [22:48] <RedBeard> i'll take that as a Good Thing(tm) [22:49] <Washu> cool [22:49] <EGreg> there are a bunch of issues I hacvent mentione,d like which is better, rendering sectors back to front or frot to back? (I and Jorrit had arguments about this for a while :) . Also, do you draw a sector twice if it's behind two open doors? Proably, yes, with different frustums. [22:49] <Nutter> that's a pretty standard design for an engine, so yea it is a good thing. [22:49] <RedBeard> one thing that i'm not solid on though is the actual portal frustum technique - if i may delve into implementation details [22:50] <RedBeard> i'm currently using a screen-aligned rectangular frustum, but that can easily break down if you tilt the camera a bit [22:50] <RedBeard> is there a "nice" way to make a tight-fitting frustum without doing all sorts of nasty plane clipping? [22:50] <EGreg> redbeard: I had code that I did for the engine i wrote 2 years ago, but try here: gamecode.tripod.com/tut/ [22:51] <Nutter> the portal engine series on flipcode discusses using frustums with portals I believe (as it's a very important part of portals) [22:51] <RedBeard> yes, the concept of the frustum is important [22:51] <grok> i think active edges or something like that help alot [22:51] <RedBeard> but there are various ways to represent a frustum [22:52] <RedBeard> one other thing that you can do with a portal engine is make rooms that have the appearance of sharing the same space [22:52] <RedBeard> i've partly implemented that feature into my engine, but it's not finished yet so i won't go into details yet [22:52] <EGreg> the basic idea: frustums are defined by planes. The normal vectors should poitn inward. THe plane is defined by the three points: eye, p1, p2, where p1 and p2 are points on a particular edge of a convex polygon. If you take all the edges together you generate all the planes for the convex frustum [22:52] <EGreg> however there's a little snag which I talk about in the tutorial: adjusting the normals to point inward. I do this by comparing the dot product with the "average" vector... it's in the tut. [22:53] <Nutter> how do you mean 'share the same space'? Portals are also very good for things like TV monitors and mirrors too don't forget [22:53] <RedBeard> ever seen screenshots or stuff for Prey? [22:53] <EGreg> nutter: I think he means rooms that intersect in world space but not object space :) [22:53] <RedBeard> if not, look up the E3 98 video (i think 3dgamers.com has a copy somewhere) [22:54] <grok> Nutter: you are in a room with two door opposite each other, you stand in between them and fire a rocket out one door, and promptly get your own rocker up your arse :) [22:55] <grok> *rocket [22:55] <RedBeard> yeah, that's kind of the basic idea [22:55] <Nutter> lol, ok that explains it well grok ;) [22:55] <EGreg> lol yes :-) [22:55] <RedBeard> there are some pathological cases when you make that feature seamless with "normal" portals though [22:55] <EGreg> but it's only kind of like that, hehe. [22:55] <RedBeard> such as objects intersectin the portal [22:55] <EGreg> yeah portals can handle everything dynamically and they are fast, i dont know why people use BSP. [22:56] <RedBeard> like i said, i'm not done implementing yet [22:56] <RedBeard> EGreg - BSP is still good for the polygonal things [22:56] <Exellon> how might you apply *special* special effects to the doors of the portals? such as an air rippling wave effect to make it look like a wormhole, or something like the wormhole effect in SG-1 [22:56] <RedBeard> i actually use a hierarchical octree/octree/BSP system - or will when i get the implementation done [22:56] <grok> BSP are good for a great number of things...collisions and line of sight being the othe 2 biggies after visibility.... [22:56] <nuvem> EGreg: You can use BSP with portals you know [22:56] <RedBeard> you can just render some fancy polygons over the surface of the portal [22:56] <Nutter> egreg: well a lot of engines use both portals and BSP's [22:57] <EGreg> nutter: Yes [22:57] <EGreg> i'm just wondering why armack used it in quake 3 [22:57] <EGreg> when he could have done so much more with hardware accelerated portals :-) [22:57] <Exellon> well, RedBeard or masterg send me a channel log when the discussion's over please (tonyburns88@yahoo.com) [22:57] <Nutter> probably a mixture of 0-overdraw and legacy code I'd think [22:57] <RedBeard> because he was just extending quake 2 really [22:57] <Exellon> i best be off to sleep now [22:57] <EGreg> i know he likes to recode stuff so recoding the design tools wasnt a reason.... right? :-) hehe. [22:57] <grok> he was too busy making out?? [22:57] * Parts: Exellon (tonyburns8@68.112.207.33) [22:58] <EGreg> 1 word: honey monkey moon [22:58] <EGreg> :) [22:58] <EGreg> j/k [22:58] <Nutter> hehe [22:58] <EGreg> things intersecting the portal: draw back to front in that case. [22:59] <EGreg> hehe. [22:59] <RedBeard> the problem arises when you can see it side-on and the object would protrude out the back of something [22:59] <Nutter> yea, he does seem to have got lazier since he got married.. but that's allowed, he's worked enough to earn it (and if he wasn't lazy, his wife'd probably have killed him, so that's worse than doing normal amounts of work) ;) [22:59] <EGreg> but really, you should daw two versions of the thing, one in each sector.... for pathological cases like a floating portal in midair where a snake is both behind, in front and through the portal :-) [22:59] <EGreg> lol [22:59] <EGreg> hehehe. [22:59] <RedBeard> possibly [22:59] * EGreg thought adrian carmack was john's wife [22:59] <EGreg> hehehe. [23:00] <Nutter> O_o hehe [23:01] * Joins: sgstair (sgstair@rn-98-26.reshall.k-state.net) [23:01] <RedBeard> EGreg - on the note of drawing things twice, linked with HW T&L [23:02] * Joins: markf (markf@evrtwa1-ar6-4-46-205-178.evrtwa1.dsl-verizon.net) [23:02] <RedBeard> if you're lumping things into vertex buffers and appropriately NOT messing with them once they're stored, you can keep a "pass index" or something on each vertex buffer for whether it's been drawn or not, and the z-buffer should hopefully resolve things [23:03] <RedBeard> ie, don't clip any polygons to your frustum, just figure out if the polygons in a vertex buffer are within the frustum, and render them if so [23:04] <RedBeard> for doing things like transformational portals that don't connect in the same space, you would have to use an incremented pass number and possibly wipe things out [23:04] <RedBeard> (in the z-buffer) [23:05] <RedBeard> and it's a fairly well-known fact that new hardware likes things to be rendered roughly front-to-back, to exploit fast-z-out circuitry [23:05] <grok> btw, all those things you read about dynamic vertex buffers being fast.....are all lies!!! :) [23:05] <RedBeard> yes, i know [23:06] <RedBeard> practical AGP bandwidth is about 10% of what they say it can do [23:06] <RedBeard> i've heard from a reputable source that he can get about 1000-1500 vertices per millisecond on geforce2/3-class hardware [23:06] <RedBeard> and that's wildly optimized [23:07] <Washu> however, with VRam coming in increasingly higher amounts [23:07] <RedBeard> using advanced vertex shaders might alleviate the problem of CPU-side vertex animations though [23:07] <RedBeard> to an extent [23:07] <Washu> and newer bus technologies (not AGP 8x, but completely new bus styles) coming out [23:07] <terminate> blarg [23:07] <RedBeard> i haven't seen any definitive tests on that note [23:08] <terminate> I need some help brainstorming [23:09] <terminate> I am looking for papers on various graphical effects [23:09] <terminate> anyone know some good sources off the top of their heads? [23:09] <RedBeard> developer.nvidia.com [23:09] <grok> terminate: www.cgshader.org? [23:09] <grok> er maybe with an s [23:10] <Nutter> graphics.stanford.edu/papers [23:10] <terminate> they have all sorts of shaders, but I am looking more for theory stuff [23:10] <Nutter> stanford has some quite nice papers on theory [23:10] * grok is there... [23:11] <grok> er so when is the next lecture happening? [23:11] <terminate> thanks [23:11] <RedBeard> oh, on the note of destructible geometry (also possible with portal systems) here's a post by the guy who did Red Faction's GeoMod code: www.gamedev.net/community/forums/topic.asp?whichpage=2&pagesize=20&topic_id=124869 [23:12] <Nutter> www.cgl.uwaterloo.ca/Projects/rendering/Papers/ <-- another good one [23:12] <nuvem> Vertex shaders can help a lot, even for particle systems (though they limit what you can do with them) [23:12] * nuvem doesn't see what he wrote... [23:12] * nuvem scrolls down... d'oh [23:14] <terminate> the second thing: I am trying to think of a cool, but reletively simple demos to work on with Cg [23:17] * Joins: blip (~asdf@co-ratlsnk-u1-c5c-221.clspco.adelphia.net) [23:18] <blip> discussion over? [23:19] <RedBeard> it's pretty much done, yeah [23:21] <blip> Are there going to be scheduled lectures in here on a weekly basis or anything? [23:21] <RedBeard> i wouldn't say weekly, but whenever someone wants to set something up yeah [23:24] * mittens[mooooovie] is now known as mittens [23:27] <RedBeard> so if anybody has a topic of discussion for a future session, lemme know when you can do such a thing [23:29] <Nutter> just something that I think would be useful - full logs of the discussions should be made available online for download [23:30] <RedBeard> ok [23:30] * Joins: The_Reindeer_Effect (~edavis@12-237-134-29.client.attbi.com) [23:30] <RedBeard> i'll see what i can do, i'll try to post a copy of tonight's log onto my website and post a link in the topic [23:32] <The_Reindeer_Effect> What's your site? [23:32] <masterg> most likely andyc.org/ is being referred to. [23:34] * Quits: Washu (direwolf@adsl-64-170-153-208.dsl.sntc01.pacbell.net) [23:34] <RedBeard> yeah [23:34] <blip> I list of specific topics people are interested in might be compiled. People can look at that and see if they know something others would be interested in. [23:36] <RedBeard> ok Text file last modified on April 28, 2007, 10:28:23 PM, MST. |
|
All content Copyright © 2025 Andy Campbell. Permission to reproduce content, in any format, by explicit written permission of author only. |
"Live every day as if it were your last, because one of these days, it will be." - Jeremy Schwartz |