RobertBeckebans

Each point light requires 6 shadowmap pyramids and that is where Carmack's performance problem came from. The original code was like for each point light: for each shadowmap pyramid: draw occluders in the pyramid draw interactions with shadow map for masking and use up to 16 samples from the shadowmap for the noise filter where you also have 16 texture lookups to determine a random spot to make it smooth and he even did some strange stencil shadow masking stuff. my algorithm is like many standard implementations: for each point light: for each shadowmap i in pyramid: draw occluders in the pyramid into a shadowmap array draw interactions with shadow map for masking and let the shader determine which shadowmap it is and use a Poisson filter with 12 samples and only 1 noise offset texture read -> 13 vs 32 texture samplings NOTE: the light interactions are drawn in the outer for loop If you go that route then you have 3 ways: a) write 3 different interaction shaders for 3 different light types (point, spot and infinite) write a single shader that uses samplerShadow2DArray (my implementation and requires OpenGL 3.1) c) use a virtual shadowmap that uses a second texture for shadowmap texcoords indirection More interesting is that the BFG shadow mapping filter with 32 samples was also used in Rage You can find all Rage shader sources in the Level SDK. Shadow map filtering is a huge topic for itself and there is a lot of stuff that you can make wrong. I tried pretty much every approach in XreaL (ESM, VSM, EVSM, PCF) and my current solution is way more elegant and even faster. One interesting approach is also to use a giant shadowmap megatexture where you have a virtual shadowmap for all lights in your scene and you only redraw parts of it when something within a light has changed. Tesseract uses that approach but it requires at least 512 MB VRAM texture afaik. I can recommend to do some search on the Poisson topic because Crytek also used it for the Cryengine. http://www.opengl-tutorial.org/intermediate-tutorials/tutorial-16-shadow-mapping/#Poisson_Sampling

@revelator this was one of my early attempts to fix draw_exp.cpp from Carmack. The BFG edition shipped the required ARB shaders. https://dl.dropboxusercontent.com/u/22890478/Doom3/draw_exp-carmack.zip Carmack's early attempt was shit performance wise and I did it a lot better in RBDoom-3-BFG however it is a good starting point.

Although it compiles fine on the 32 bit edition. Compile log: g++ -DHAVE_CONFIG_H -I. -I.. -DPKGLIBDIR='"/usr/local/lib/darkradiant"' -DPKGDATADIR='"/usr/local/share/darkradiant"' -I../include -I../libs -D_REENTRANT -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -D_REENTRANT -I/usr/include/gtkglext-1.0 -I/usr/lib/gtkglext-1.0/include -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/pango-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/freetype2 -I/usr/include/directfb -I/usr/include/libpng12 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/atk-1.0 -I/usr/include/libxml2 -DRADIANT_USE_GLSL -DPOSIX -g -O2 -Wall -Wno-unused-variable -MT darkradiant-AnglePropertyEditor.o -MD -MP -MF .deps/darkradiant-AnglePropertyEditor.Tpo -c -o darkradiant-AnglePropertyEditor.o `test -f 'ui/einspector/AnglePropertyEditor.cpp' || echo './'`ui/einspector/AnglePropertyEditor.cpp ui/einspector/AnglePropertyEditor.cpp: In static member function 'static void ui::AnglePropertyEditor::_onButtonClick( GtkButton*, ui::AnglePropertyEditor*)': ui/einspector/AnglePropertyEditor.cpp:79: error: cast from 'void*' to 'gint' loses precision make[2]: *** [darkradiant-AnglePropertyEditor.o] Error 1 make[2]: Leaving directory `/home/me/0/software/darkradiant/svn/darkradiant/radiant' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/me/0/software/darkradiant/svn/darkradiant' make: *** [all] Error 2

This is a patch that fixes a problem with images like: diffuseMap textures/eX/eXmetalBase04.tga It worked fine if you loaded it directly from the PK4 archive but it failed if you tried that with the image in the mod directory on Linux. Patch: http://xreal-project.net/wp-content/tmp/Da...Fix_r4846.patch

Yeah thank you for this feature. I was looking for this feature for our target_fx particle emitters.

The XreaLRadiant is almost the same code as the DarkRadiant with smaller changes all over the place like missing PK3 support, .PNG image file support and other stuff not supported by id Tech 4. We go the same route as Doom 3 concerning the detail brushes issue. The detail flags are ignored and instead we merge func_static entities as detail brushes into the worldspawn entity in the XMap2 map compiler. Quake 4 goes even further and removes the unused detail flags completely from the .map format.

I have a problem. I still work on an entity definition file for XreaL. I would like to use the rotation tool to have abitrary rotations for the following entity: entityDef info_player_intermission { "editor_color" "1 0 1" "editor_mins" "-16 -16 -16" "editor_maxs" "16 16 16" "editor_rotatable" "1" "editor_usage" "Camera for intermission screen between matches. This also automatically generates the podium for bot arena matches (see Notes). Can be aimed by setting the 'angles' key or targeting an pointing to an aiming entity. Use only one per level." "spawnclass" "idPlayerStart" "editor_var angles" "alternate 'pitch, yaw, roll' angles method of aiming intermission camera (default 0 0 0)." "editor_var target" "point this to an info_notnull or target_position entity to set the camera's pointing angles." "angles" "0 0 0" "target" "" } However I cannot get it to work. It looks like "angles" as keyword are not support by DarkRadiant at all. I just want DarkRadiant to set the "rotation" keywork and to show me the direction of the forward vector but it only sets a yaw "angle" keyword all the time. Any suggestions?

That sounds good. I think I only need very few changes or extra stuff like PNG image support that already works. Concerning the XMap2 observer .. well I think we don't need that because most mappers use an extra GUI frontend for XMap2 (Q3Map2) anyway. I wrote a bunch of .def files to get the DarkRadiant to work with XreaL. However it contains only a few entity defintions by now. I think I can handle basic XreaL support even without extra plugins.

I only wrote smaller fixes for the GtkRadiant 1.5 tree a long time ago and helped SPoG with Doom3 tech questions. Ok I created a patch for the shader names. The patch is not perfect with the functor solution but I don't know another way to do this in C++. I used the same technique in my previous C++ based engine. Maybe you have a better solution. This is just a suggestion as a result of a short code review. You really changed almost everything .. I have to start from the beginning I left out the shaders.vcproj because VC9 changed it a bit more. Here is the patch generated with TortoiseSVN: http://xreal.sourceforge.net/files/darkrad...ive_r3395.patch

I compile with Vista 32 bit. Doom3 material names are definitely case-insesitive. I just checked that with the media browser of d3radiant. I'm going to provide a patch for that soon. Well XreaL is basically the Q3A engine with a Doom3 style renderer and new artwork to make it a standalone funny thing. But it is a very specific solution. I still use the Q3A BSP for rendering but with static VBOs and dynamic IBOs. I use Doom3 style lights and have almost full support for the entire Doom3 .mtr language. The renderer is written on top of Carmack's Q3A trinity renderer so everything is written in C. It's not suitable to grab the renderer and make it work for other programs because it heavily relies on the Q3A framework and architecture. I have a lot experience with OpenGL. XreaL's renderer is even better than the Doom3 one in a few areas. However the DarkRadiant code is something completely different. GtkRadiant 1.5 uses my old .cg shaders for the light preview mode but I haven't coded the renderer implementation. That was SPoG's work. I only have time for coding at the weekends so I can't promise too much. I think I will try to improve DarkRadiant's renderer after I'm done with the XMap2 observer. I guess even that plugin will take a few weekends.

Hello everybody, this is my first post in this forum. I'm the lead coder of the XreaL project and I just want to say that I really like your work on the DarkRadiant. The coding style is very good and some of the new features like the model previewer are really handy. It's really nice to see that you put so much effort into this level editor to give people a useful tool. I worked most of the time with a GtkRadiant 1.5 codebase with a very few hacks. As you might now I use the Q3A engine and I compile Doom3 .map format maps into the Q3A BSP format. The Doom3 .map format is the standard format for our project and my XMap1 compiler can convert any Quake .map ranging from Quake2 - 4 to the Doom3 .map format. So a Doom3 .map format only editor is the only thing I need. I just want to let you know that I could compile the latest DarkRadiant SVN code with the VC 9 express edition and I can offer a few patches in the future if you don't mind. I use your win32 deps and a separate complete build of boost 1.35. It works fine with that and I'm glad that STLPort is not necessary anymore. However I had to add the OGG Vorbis source to the sound plugin because the binary libs for linking are too old. (oh well libraries and win32 .. always crap) Well I don't have much time this semester but I could provide a few fixes because I'm almost done with XreaL's renderer. I'm going to try to use DarkRadiant as the main editor for XreaL when I'm done with some necessary plugins like a XMap2 compiler observer plugin. Do you accept some non-darkmod specific plugins? I already backported PNG image support and changed the mediabrowser to display Doom3 materials with a case-insensitive lexicographic comparison, so materials with Textures/foo/bar and textures/foo/bar don't create extra trees. The only downside with the DarkRadiant is that it is about 3 times slower than the old GtkRadiant 1.5. I haven't profiled it yet. I just noticed that it gets really slow when there are many brushes and patches visible in the 2D view. I haven't looked much into the renderer yet. Do you render all brushes individually? Maybe that can be improved with dynamic VBOs where you merge the geometry by material every few frames with all brushes that haven't changed. I use a lot of tricky optimizations in my engine like that and maybe I can improve the renderer speed in DarkRadiant once I found the bottlenecks. Well that's it for now.