Gildoran

As for splitting Node into Layered and Filterable, is that to make it clear that each set of functions works on different data and they have no effect on each other? (I ask, because splitting Node wouldn't have occurred to me, and I'm wondering what the design reasoning behind it is) Could you elaborate on this? I'm not sure if I understand what you mean. (my best guess is that by "parallel" you mean "closely related", since I think of "orthogonal" as meaning "independent")

I believe the technical term is a Fecal Recognition System. It's a new branch of AI that is finding applications in airport restroom security. If Osama ever takes a dump in any of our restrooms, we'll be prepared!

I wanted to add another idea that I hadn't seen. This would likely turn out way too complicated and difficult and error-prone, but perhaps it's worth mentioning... What about importing/exporting map files, and comparing maps before/after being edited by D3ed? For example, you create a big complicated map with all sorts of grouping and layer info and save it in DRmap format. When you compile the map, DR exports it and saves a backup D3ed map file. You could then go around moving ragdolls, setting up lights, etc, and save the D3ed map file. Going back to DR, you select "commit changes" and DR pops up a list of changes you made. You can check/uncheck specific changes and commit them to your DR map. This would work by DR parsing and comparing both D3ed maps. It would understand only certain limited types of changes (such as adding/removing an entity, changing spawn args or repositioning a ragdoll). Certain kinds of changes couldn't be committed without losing grouping information. For example, adding/removing worldspawn primitives would lose all worldspawn grouping info because DR wouldn't know exactly which primitives were added/removed, only that worldspawn's primitives changed. This is far from an ideal solution, but it might act as a stopgap measure until a renderer and ragdoll editor are created for DR...

I was wondering, are we eventually going to want to support grouping hierarchies? How might we save that? I can think of a couple of possibilities: One would be to create our own map format and be able to import/export to D3 maps. (I know from editing HL1 maps that this is entirely viable) Or maybe we could embed such information in comments in D3 maps. (I'd be a bit worried that somebody might accidentally open/save their map in D3ed and lose all their meta-info and be pissed) Assuming for the moment that grouping will exist, what kind of effects would this be likely to have on the scene graph and space partitioning? What kinds of things could a group contain? At first, I was tempted to say: WorldSpawn primitives Entities Groups Maybe entity primitives under certain circumstances? It seems like being able to group subsets of an entity would be useful, but I dislike the idea of a group that contains primitives from two different entities. After thinking about it, I've come to the conclusion that I think of entities as an implicit group, and I want to think of the group hierarchy as a tree. Having a group that contains primitives from two different entities would make the grouping hierarchy a directed acyclic graph, not a tree. On the other hand, I want to be able to make a group that contains an entity and a WorldSpawn primitive. I guess I don't really think of WorldSpawn as an implicit group. The more I consider it, the less I believe WorldSpawn should really be treated like an entity. The user interface doesn't treat it like an entity (eg, if you select one WorldSpawn primitive, it doesn't select them all), except that it has spawnargs. And I don't think most users really think of it as an entity, even if it technically is. I'm starting to wonder if treating WorldSpawn just like any other entity would require a lot more special code (especially for hierarchical groups) than just attaching any unassigned primitives to WorldSpawn when the map is saved. Any thoughts on this?

Even worse than slapstick oil flasks? And always having exactly 3 special loot items per mission? Even though I don't care for this idea, I'd hardly call it a bad one. At least it would be subtle if implemented right.

No, I'm saying it uses an octree to skip the vast majority of the entities. It doesn't iterate through all of the entities in the map (unless the drag-selection rectangle intersects the entire map). If it turns out to be necessary, perhaps it would be possible to create some kind of SpacePartition that alternates data structures based on a threshold? (eg, less than 16 Primitives and it tries to conserve memory, more and it moves everything to an efficiently culling structure) To be honest though, I don't think it would be necessary since Doom 3 draws things on an entity by entity basis. If the banister is small enough to not cause D3 problems, it probably won't give us problems either. Then again, we don't have a BSP PVS, so I could be mistaken.

Note: If you prefer, replace Entity with entity Node and Primitive with primitive Node. Yeah, I tend to edit my posts a lot after I write them. I'm addicted to the edit command. Almost, yes. I was thinking the method would return a SpacePartition so users can intersect elements, but all SpacePartitions would be usable as (castable to?) a Set. (Note: Set might end up meaning std::set or whatever would have a useful interface). LowOverheadSpacePartition might act like a wrapper for std::set. No... In practice, the LevelMap (I've decided not to call it Doom3Map anymore ) would have a large Octree of Entitys and WorldSpawn would have a large Octree of Primitives. The thousands of Entitys would each have a LowOverheadSpacePartition of Primitives. LowOverheadSpacePartition would be designed to provide the interface of a SpacePartition but use as little memory as possible. It wouldn't be able to quickly cull things or quickly add/remove Primitives because I figure if you can see a (non-WorldSpawn) Entity, you can see all of it, and I assume adding/removing primitives to/from it wouldn't be a bottlenecked operation. No, it means we have to iterate over all Entitys that intersect the drag-selection rectangle. WorldSpawn would almost certainly be hit, but most other Entitys wouldn't. That's what I'm thinking too. Bear in mind, I'm no expert on space partitioning either so I'm all ears for other techniques. It was my fault too... I should get out of the habit of leaving my posts in the open while I'm editing them. *waves and heads off to bed*

The main idea behind the above design is to think of a SpacePartition as nothing more than a set that can iterate over intersections quickly... as such, there's no reason to make SpacePartition a singleton class. Whether or not everything is a Node isn't something I care about much... I just set up the example design that way because having a map which contains entities which contain primitives seemed like the simplest way to do things to me. Are we planning on handling anything drastically different from a Quake architecture? What did you have in mind? I was under the (mistaken?) impression that part of why we're redoing the scene graph was because DR had efficiency problems with intersecting large quantities of brushes. Could you point out which parts of the design had behavior that was too Doom3 specific?

Here are some illustrations to hopefully ... uh, illustrate what I'm thinking of for octrees. To start out, we have a few shapes in a level (maximum level extents are indicated by blue) When we place the shapes in the octree, we put them in the smallest reasonable octree node that their origins are inside. It is debatable exactly which octree node depth is best - my prefered heuristic would probably be to place them such that their AABB is half the size of their containing octree node. Similarly, it is debatable what exactly constitutes an "origin", but I think putting it in the center of the AABB minimizes octree node sizes. In this picture, shapes 2, 3 and 4 are small enough to fit in the third-level octree nodes. Shapes 1, 5 and 6 are too big and must go in second-level octree nodes. Then each octree node needs to be expanded to contain the bounds of its children. When deciding where to add new shapes, we consider the original octree node bounds, not the expanded bounds. It is perfectly fine for octree nodes to have overlapping bounds. It doesn't hurt searching, and in fact we want to be able to discard an octree node's children if its bounds don't intersect our test shape. Each octree node can have at most 8 octree nodes as children, but any number of shapes as children. I think a worst case mapper scenario would be to remove a single log from a large pile of them. The logs are very long, so they end up pretty high in the octree, and most likely will all end up in the same octree node. After removing a single log, we have to recalculate the bounds of the octree node, which means going through and taking the maximum extents of all the AABBs of the logs. (if we needed to be fast, we could probably use a heap-like structure to accelerate rebuilding bounds, but that seems overly complicated)

Is there a good reason to put Entitys and Primitives in the same SpacePartition? Since a scene graph could be pretty flat, maybe it would be simplest if we could think of SpacePartition merely as a set which can efficiently iterate over elements that intersect something, rather than go to the trouble of having a single SpacePartition keep track of all levels of the scene. This would perhaps allow SpacePartitions to know nothing about the scene graph. Here's one possible example implementation: SpacePartition would be a subclass of some kind of Set API, but it would define additional functions to iterate over objects intersecting something. This way, objects that only know about Sets can at least iterate over an entire SpacePartition ... a map exporter may want to do that. There would be a Doom3Map object that has an entities() function. entities() returns a reference to a SpacePartition<Entity> to users wanting to iterate over its Entitys. This might be implemented by returning a reference to an Octree<Entity> member. Entity would have a polymorphic function primitives() which returns a reference to a SpacePartition<Primitive> containing its primitives. WorldSpawn might implement primitives() by returning an Octree<Primitive> member. Other, smaller entities might implement primitives() by returning a LowOverheadSpacePartition<Primitive> member. LowOverheadSpacePartition might simply be implemented in terms of std::set and use linear searching to filter out elements. This could have the disadvantage that to iterate through all the Primitives in a Doom3Map, we'd need two loops: RayTest ray( mouseclick ); SpacePartition<Entity>::IntersectionIterator entity; for ( entity = map.entities().intersecting(ray); entity; ++entity ) { SpacePartition<Primitive>::InsersectionIterator primitive; for ( primitive = entity->primitives().intersecting(ray); primitive; ++primitive ) { primitive->doSomething(); } } Of course, if this were a problem, we could make a primitives() function for Doom3Map that returns an adapter whose iterators implicitly iterate over entities. To filter for specific kinds of Entitys, two routes would be possible: For specific cases that need to be optimized, we could declare additional SpacePartitions to keep track of specific sets of objects (more than one SpacePartition would point to the same object). To quickly iterate over Lights, we might have an Octree<Light>. To keep track of which Entities are currently visible or hidden, we might have a couple of Octree<Entity>s. Unfortunately, I'm unsure of the best way to have an entity update a SpacePartition when its AABB changes... (would callbacks be reasonable?) For filtering in general, we might simply iterate over a SpacePartition and disregard objects not matching our filter. For example, to find only Lights that are visible, it might be easiest to iterate over map.lights() and disregard any light that's hidden.

As for how to quickly add/remove/cull nodes, I wanted to suggest a variation of an octree that's similar to what's used where I work. I didn't see this described in Wikipedia so I thought it might be worth bringing up... (please forgive me if this is well known or obvious) Assume an entity's AABB contains its origin. Each entity is placed in the smallest octree node whose original bounds contain the entity's origin and are larger than the entity's AABB (the octree node's bounds don't necessary need to contain the entity's AABB - they just need to be larger than it - this is a heuristic to place the entity at a reasonable depth). Then starting at the deepest levels and working our way up, we expand each octree node's bounds to contain the bounds of its children. To add/remove an entity, you just need to find the correct octree node for that entity, then work your way back up, recomputing bounds as you go. I think it would typically end up having logarithmic performance. Iterating through the entities that intersect something is also cheap, since this forms a BVH where each child often has about 1/8th the volume of its parent. Also, it's a tree of AABBs, not an acyclic graph, so finding each entity only once would be easy. Also, I think a map could be imported in close to linear time (or at worst n*log(n)). Edit: It occurred to me that worldspawn is just a single entity and I was thinking of each worldspawn primitive as being separate when I wrote this... I suppose worldspawn would have an octree to keep track of its primitives.

I was wondering... how are mappers likely to apply layers? Are we thinking one layer per room/area, or global for a certain style of entity, or both? What kind of layer interface will be presented to mappers? If mappers want to use one layer per room and they have to manually add/remove entities/brushes, that could get tedious and error prone for them. This suggestion might be too complicated, but I thought I'd throw it out there... What about allowing the mapper to additionally specify several bounding boxes for each layer... and anything intersecting such a bounding box would be implicitly added to the layer (or removed when it's no longer touching the bounding box). That way, whenever you move an entity, it automatically gets added-to/removed-from the correct layers. Also, such layer bounding boxes might be an easy way to leverage the intelligence of the mapper to make better BVHs.

...just like everybody thought locking the view was an intrinsic part of readables before I coded them? I don't buy that at all. Doing body awareness without locking, modes or clunky controls is every bit as doable as readables without locking the view. It may take more coding (and hence wouldn't be a TDM 1.0 feature) but it's certainly possible to have body awareness without sacrificing control. Also, without body awareness, player shadows and reflections will not render correctly - they'll be prone to graphical artifacts. In the case of player shadows, Doom 3 is designed under the assumption that only visible objects will cast shadows, so geometry won't be shadowed in any place where the player model clips into it. In the case of reflections, how do you not show the player, but show their reflection when they're wading? What would that even look like? Do you see your guts when you look straight down?

I was browsing through the textures and I noticed a set was seperated: textures/darkmod/stone/brick/pillar_bricks01 textures/darkmod/stone/brick/small_brown_bricks01 textures/darkmod/stone/cobblestones/flagstones01_light The only reason I had constructed those textures was to have several variations of the same stone texture with different shapes useful for different applications. (before, I couldn't have created a fireplace with the existing textures since they were mismatched) As these three textures are named now, if a mapper finds one texture, there's no clue the others exist and can be used together. In my opinion, they need to be named with the same path and differ only in suffix so that they appear adjacent to eachother. ...or is there another way we're planning on handling sets?

*cough*wiki*cough* You don't need a detail texture, but they're very cheap if you want to do one.

As long as you don't care about the candle looking the same from all directions, I don't see why not.

You mean the semi-automatic blunderbuss, right?

Actually, dogs were what I had in mind when I said that pure-breeds have health problems. I would argue that though their appearances are the result of concerted selective breeding, their friendly behavior is inadvertent evolution due to killing aggressive dogs; note that even mutts are perfectly friendly despite not having eugenics directly applied to them - and they're healthier. I doubt it would have nearly as big an effect as you seem to think it would, and to be honest, I think there are other (less distasteful) social reforms that would have a bigger impact with less risk of being corrupted. Keep in mind it wasn't so long ago that atheists were considered unfit parents.

Even ignoring how it has turned out in the past, I'm against mandatory eugenics. Who gets to decide what genes are worth propagating? Some traits may look inferior yet prove enormously useful in unexpected ways. Consider that Einstein was thought to be retarded as a kid - perhaps a candidate for sterilization under eugenics guidelines. And look at what has happened when even the most diligent humans have applied eugenics to animals ... pure-bred animals tend to have lots of health problems. Additionally, a lack of genetic diversity tends to result in populations with less disease resistance. I think nature/reality does the best job of deciding what genes are effective and what aren't, not some group of self-proclaimed experts. Having said that, I'd be all for offering money to people to get sterilized. A while back, there was a program in the US that offered $1000 to any crack-addicted woman who agreed to undergo sterilization... until the religious people got their hands on it. I guess God wants suffering crack-babies born to mothers who don't care about them.

I was thinking the same thing, except I was wondering if "deform sprite"s wouldn't have lightgem flickering problems...

Hmm... I'm not seeing anything obviously wrong with the shader. I'll have to go try that and see if I can get it working myself... Actually it occurred to me that I've only tested lighting with particles (which behave just like sprites), not specifically "deform sprite". Are you saying the material works when you take away "deform sprite"? If so, I may have to eat my own words about sprites being able to receive lighting... Another possibility, which may have a similar effect, would be to use a particle deformation instead. You could make an alpha-tested leaf texture (without deform sprite), make a particle effect that uses it, and then make an invisible material that emits those particles (sort of like how SneaksieDave's rain map uses a surface that emits rain particles). I guess that would only work if you could come up with a particle effect where the particles don't fade in/out. PS, I love your textures!

Could you describe what you want to do in more detail? Contrary to popular D3W belief, sprites can receive lighting and have normalmaps just like anything else. After all, D3 uses a unified rendering system, so a sprite can have any material that geometry can have. However, regardless of whether you're using sprites, you may have problems with translucency and alpha maps, depending on what you want to do. It's possible to use alpha-testing to punch out holes, so leaves are correctly shaped. Alpha-tested materials will be correctly drawn, receive shadows, etc, so they're perfect for foliage. I strongly recommend using alpha-tested surfaces for trees and such. It's sort of possible to have lighting/specularity on a translucent surface (not to be mistaken for an alpha-tested surface), but there's severe problems and limitations to that. For example, shadows require depth-buffer information, so translucent surfaces will not be hit by shadows. Furthermore, there is no depth-sorting of translucent surfaces (though D3 does have categorical sorting of surfaces), so you'll get severe graphics errors if you try to use translucent surfaces to draw leaves. Also, all the lighting passes will be rendered additively before any custom passes, so if you want some leaves to obscure others, they cannot be lit. An example of lit translucent sprites would be the test_volumetric map. However, keep in mind in test_volumetric the order in which the sprites are drawn didn't matter (unlike leaves) and the light doesn't have real shadows. Also, the map was very expensive. For more information, you might check this discussion on the alpha-channel, translucency and depth-sorting.

I'm an American. Though I'm for second amendment rights, I don't own a gun, nor do I intend to. Where I live, I feel pretty safe; I've never been mugged or personally seen anything violent. The only gunshots I've occasionally heard were target-practice (I live out in the boondocks) and the only real guns I've seen were holstered on police. Not all of America is like Philadelphia. In truth, much of the violence I've heard about is by police, not citizens. Not so long ago, the Portland police shot a black man to death for forgetting to use a turn signal. Forget trying to get guns out of the hands of individuals... if you really want to decrease gun violence, get them out of the hands of police! (that last sentence isn't intended to be taken entirely seriously)

I've always interpreted the second amendment as not about protection from individuals, but from the government, and complimentary with the notion that citizens have a right (and duty) to revolt against an oppressive one. Sure, guns may not keep the government from apprehending an individual, but whether or not a populace has widespread possession of guns could affect how easy or difficult it is for them to overthrow their own government. Edit: Whoops, I had the wrong number... I tend to remember what the amendments generally say, but not their order.

I'm saying that much like how unrestricted quicksaving ruins Tetris, it ruins TDM, since Thief-like games depend on risk-analysis and backup plans, but unrestricted saving bypasses those.