namespace

I'm experiencing the same problem as described above. My system is a a 64bit Arch Linux. Here are some stats: Linux xen 2.6.36-ARCH #1 SMP PREEMPT Sat Jan 8 14:15:27 CET 2011 x86_64 glibc: 2.12.2-1 This might help (the devs): https://bbs.archlinux.org/viewtopic.php?id=50230

Strange, we used VC2k5 in the past development phase and for the release build. Did you download the gtkr-dependency package?

Gtk comes with already setup VC2k5 projectfiles, what are the problems?

So gcc is implementing dynamic_cast<> in an unreliable way? I can't believe it. Well I think they made it as reliable as possible, I have no idea how a compiler should store the required metainformation that type X inherits from type Y that is implemented elsewhere.

This seems to be one of the issues why C++-rtti was avoided in the first place. I never experienced these problems my self, this is a surprise for me too. I did some googleing and found, aside from many many bug reports, some example code for gcc 3.3 that exposes a dynamic_cast bug: class cFoo { ... }; class cBar : public cFoo { ... }; cFoo* pfoo = CreateBarInDLLAndCastToFoo(); cBar* pbar = dynamic_cast<cBar*>(pfoo); // pbar is zero Since we work alot with shared libraries, a similar scenario would be possible... In my opinion, a cast mechanism that "might" work is unacceptable, we should try to implement our own cast-mechanism.

Thanks, it compiles now. Starts up nicely, but crashes when I try to create a bursh. I'll wait until the transition from the ugly cast-system is complete.

A compiling darkrd on Ubuntu would be cool and would it make possible for me to do some little changes (vbos etc) myself. So far I always got a scons related error: scons: Building targets ... scons: *** Directory /home/cc/Projects/darkradiant/trunk/darkradiant/libs/string found where file expected. scons: building terminated because of errors. I searched the forums and the suggested way to fix this is to install an older version of scons. However, this is no option for me since two of my projects rely on the recent (96.92) scons-version.

A failed dynamic_cast on a references throws a std::bad_cast exception, dynamic_cast on a pointer returns 0. I think it was done this way to evade exceptionhandling.

The cube-grid is just a additional structure and can't be a replacement for the real scene-graph, so it can be added later. The uniform-grid makes some things really clean and fast. Example, we spawn an entity and have to upgrade the cube-grid: Assumption: We have small list for each entity which stores in which cubes this entity is in. Put the entity in cube[x / 256 + 256][y / 256 + 256][z / 256 + 256] See if the entity interects the neighboring cubes, if so, add the entity to these cubes as well. This information has to be updated when the entity: - moves - resizes - gets deleted (The cool thing this is that these conditions only relate to this entity, there are no "outer"-circumstances which would make a regeneration of this information neccessary) Assuming that most entities are way smaller then 256³, the reasonable worst case would be an entity intersecting 3 cubefaces, generating 3 "cube-links" instead of just one.

Divide your radiant-space (2^16 x 2^16 x 2^16) into cubes of uniform size (256 x 256 x 256) and sort your brushes and entities into these cubes. If a bounds-selection has to be performend, check which cubes would be affected by the selection-volume and then check the objects inside these cubes (-> all other entities and brushes get ruled out in a few operations). An octree works similiar, but is abit more complicated. An octree recursevly subdivides the cubes into smaller cubes until a specific object-count for each cube is reached. We won't need that. If there should be too many objects per cube (how many entities can you stuff into 256x256 ?) then we could just switch to a uniform 128x128x128 cube-grid. BSP-Trees and kD-Trees are of no use here (imho) since we work on dynamic data.

Yeah, but I question that the amount of callbacks is the slowdown. As far as I remember, radiant doesn't have any intelligent datastructure that organizes the scene in a way that would make it possible to easily reduce the amount of objects that need to be checked for a selection. *votes for uniform cell partitioning*

Fantastic news! Another weird radiant interface bites the dust

Yes, this special type of casting was introduced in the beginning of 1.5 because the early C++ compilers had crappy rtti support, some still have. I don't know on which pattern, if any, this system is based. In my opinion, the real problem is the wrong usage of this mechanism, many classes have installed casts which just return a reference to a membervariable. This messes with the semantics of inheritance and delegation, a delegation should be treated as such and not be hidden as pseudo-inheritance. So far performance was never been kept in mind when writing 1.5, it was more playing catchup with featuresets and bugfixing most of the time. Sad, but true. If you feel the urge to implement a new rtti-system, I could post some source of my engine which has its own rtti-sys as "inspiration"-source. It works with dispatching based on virtual and static functions and does not requiere any variables per instance, just one integer per-class.

Yes. Concerning the other people who were involved in 1.5: Spog: Haven't seen him for half a year in the channel, I guess he does different things now. Shaderman: I chat with him everyday, atm he extends my brushplug to support materials. In general he as no intentions to continue development, he just does it for fun. LordHavoc: He helped alot GPLing 1.4 but he hates the 1.5 code so I don't think that he would pick it up. Yes, he does most of the linux ports for id games, gamepatches and other stuff. He worked on GtkR 1.4 as open source coder and got hired by ID. (at least thats what I could figure out, can be wrong)

Yes. It doesn't make any sense to continue development as a "one man army" fighting against a chaotic codebase. I think helping you guys and working on my project would be a far better use of my sparetime then reimplementing "select tall" in 1.5 because some zealots can't live without it. Edit: Have a look at qeradiant.com. You'll notice, apart from the release message, that their isn't any other content on this page and I guess there will never be. TTimo can't find his backup and of course he didn't check for it before he deleted the old page. In case of the backup beeing found some day then it would have been my job to port the data into the new wiki system. At least thats the way TTimo planned it... without asking me. I don't want to sound bitchy but this guy was more of a constant annoyance then a help during development.

1.5 is out btw. Released it two days ago, no special changes compared to the earlier nightly builds. Feedback has been very rare and cautiously optimistic so far. Not that I really care, I feel great that its over.

You can edit the vertices of the lightfrustum? Did you guys add that in DarkRd? I made a little test myself and was surprised, I get backprojection in GtkR too. I think the only reason I didn't recognise it earlier is that Radiant culls Brushes that are behind the frustum. I never placed a light that close to a wall that this effekt would show Anyway, that shouldn't be much of a problem. Try painting the left or right half of a falloff map black, it should mask out the front/backprojection. Irrc the doom3 falloff starts in the middle of the falloff-texture, so the center of the texture is the lightvalue for zero distance, left should be negative distance, right positive. I changed that for my engine slightly: Zero distance is the left edge, max distance the right. That way I can use the full colorprecision when using a 256 pixel falloff-map. The fallofftextures have CLAMP_TO_BORDER enabled which adds a "virtual" border to the texture. This little trick kills backprojections since everything with a s-texcoord < 0.0 ends up on the black border.

Well mathematically, the backprojection is correct. The most common way to get rid of it is to use a texture to mask it out, doom3 combines this with its falloff texture. If you see the backprojection your falloff texture is completly white or painted wrong. The frustum looks distorted though.

Huh, why that? It works in 1.5.

SpoG was a mapper who started to become popular back in the Q1 (or 2?) days. He wrote many howtos about q3map2 and other id mapping related things and picked up GtkR development at the time of GtkR 1.4. Later he got his own branch because his "interesting" design decisions were a threat to 1.4. As the 1.4 crew left the project, the spog-branch became the 1.5 branch. The code for projected lights is not from SpoG. Nobody (Spog, Tr3B, me) was able to figure out how ID calculated these matrices, many implementations worked most of time but failed in some special cases. That code-snippet was given from ID. The renderer isn't from Spog either. It was backported from Tr3Bs x-real engine. I don't want to smallen Spogs work, its still alot of stuff and very complicated too, but don't give him credits for too much. Concerning the projected light code: I have no idea how it works, I know projection-transforms very well, but this code is just insane. My engine just recalculates the projection from the 3 given vectors. Thats pretty easy to do and looks intuitive enough to me. Yes it may not cover every possible weird lighing setup you can create with doom3, but I don't consider this to be a problem.

I think is absolutly ok for picomodel to use floats for vertices, since it loads staticmeshes that just get instantiated and not manipulated in radiant (or do you use it for other things too?). Storing the position and orientation of these models as double-values should be sufficient. This is just a vague memory, but I think the maya converter in the doom3 sdk generates its vertices from single precision data, so you wouldn't win any precision by using doubles here. Brushes and patches going double is a good decision, esp considering brushes with non planar surfaces.

Ok, I missunderstood your first post then These two applications would come in very handy when trying to improve gtkrs OpenGL-calls: GLIntercept: http://glintercept.nutty.org/ gDebugger: http://www.gremedy.com/ gDebugger is way more advanced then GLIntercept, have a look at the screens. The downside is, that its a commercial, non open source app. The most usefull feature of both apps is the glcall-logfile, it can be generated very fast at no cost and without modifing the application. Its way faster to analylize gl-rendering in this logfiles then it is through browsing code.

Profiling a renderer is tricky. The problem is that objects aren't draw when the application issues a glDraw command. The driver caches all your rendering commands and state changes as long as possible. There are a couple of operations which force OpenGL to flush this cache and execute your renderings: glFlush() (non blocking) glFinish() (blocking) backbuffer swapping (blocking) reading texels from the screensurface (should be non blocking when reading into gpu-ram, blocking otherwise) There may be some more, which I have forgotten. Anyway my point is that by measuring the time of all your Draw commands, you measure the times spend to process and send these calls to the driver not the actual rendering time. Measuring your glcommands and doing a seperate measure for the backbuffer flip should give more detailed informations.

Yep. A benchmark map would be nice to get comparable results across different systems.

Please don't consider dlists as something that can be recreated frequently. Thats not their intended usage pattern, use dynamic/streaming vbos for that. The "global buffer"-solution for all brushes/for each material is possible, but is a lot of work to get right. These buffers must be resized when running ot ouf space, or defragmented when a brush gets deleted. When changing a material, the faces have to be deleted from the one and created in the other buffer etc. I would favor the simple and abit stupid solution as a first step.