[http://sourceforge.net/p/ufoai/patches/535 Item 535] imported from sourceforge.net tracker on 2013-01-28 20:43:43

I've attached a large patch that fixes a number of issues with the tangentspace code; tangents and normals can now be saved to .mdx files, and will automatically be loaded if the .mdx files are found. If they aren't found, the tangents and normals will be generated, though this is very slow at the moment. I suspect more can be done to optimize the way that this is done.

I've also attached a small tarball with a few new files that I've created that are needed for the patch to work.

Mattn, would you take a look at this and try it out? The current version of the normal/tangent code is expensive in both time and memory, and I think it could be optimized, but it's now generating very pretty surfaces, and there's a parameter that you can use with ufomodel to specify how aggressively the normals should be smoothed for a given model. There's a shellscript called ufomodel-smooth.sh which automatically applies some decent values based on what directory a file is in (eg. people are soft and smooth, aircraft have more flat surfaces and sharp corners).

There's also the beginnings of a new system for handling lighting; the rendering code is in place to handle dynamic sources, but at the moment only a default "sun" or "moon" source is being used. We should probably load lights from maps somehow, but I don't really understand how lighting works for the maps right now. Are lights really associated with specific objects, rather than just lighting things nearby in the world?

It's disabled by default, but there's also an option in the new shader program for using Cook-Torrance shading, which is a method for creating much more interesting specular reflections than you can get with the Phong model (which is what we were using before, and is still the default behavior). It requires an extra texture to specify the roughness and refractive index of a surface, and it allows you to generate effects that just aren't possible otherwise. See

http://wiki.gamedev.net/index.php/D3DBook:%28Lighting%29_Cook-Torrance

for a description, as well as some examples (a ways down the page).

The game will automatically look for roughness maps (*_rm.png) and specularity maps (*_sm.png) associated with texture images; if a roughness map is found, it will be used for Cook-Torrance shading. The specularity map defines the color that specular reflections should be (as well as the implicit intensity) on RGB, and for the Phong shading model it specifies the specular exponent on the alpha channel, which controls how tight the reflective spot is. If both a roughness map and a specular map are found, both will be used in conjunction.

We can merge this into trunk if you'd like, but it's a big enough change that I wanted to at least get someone else to look at it (and make sure it works on another system) before doing so. It's also still very much a work in progress; it's at a state now where everything looks as good as or better than the old system, at least to me. There's a lot of work left to be done, both in terms of coding and in terms of artwork to take advantage of the new features before it will meet its full potential.
===== Comments Ported from Sourceforge =====

====== arisian (2010-05-01 03:01:54) ======

Patch that implements a dynamic lighting system
====== arisian (2010-05-01 03:02:28) ======

extra files to go with the r1 patch; extract in the root ufoai directory
====== arisian (2010-05-01 03:13:54) ======

Also, for testing purposes, I found it was useful to change cl_camminpitch; that will let you look more closely at the undersides of models, so you can really examine how much illumination various parts of a model are getting. I think I'm beginning to agree with MCR that it may be time to change the default value for cl_camminpitch to 0, and possibly introduce a basic skybox.
====== tlh2000 (2010-05-02 05:43:13) ======

will have a look at the patch now
====== tlh2000 (2010-05-02 05:45:58) ======

btw. we could open a branch for you if you want this. that would make patch handling a little bit easier.
====== tlh2000 (2010-05-02 06:17:41) ======

i've applied parts of it to trunk already to keep the real patch as small as possible.
====== tlh2000 (2010-05-02 06:28:28) ======

without all already applied changes
====== tlh2000 (2010-05-02 07:33:33) ======

applied coding guidelines, added light parsing, fixed segfault
====== tlh2000 (2010-05-02 07:35:32) ======

updated my patch - please try to use that one.

- fixed a segfault in ufomodel
- started to work on "make models" (models.mk)
- what about the whole R_ModLoadBspLights system? can we remove it now?
- added light entity cl_parse.c functions to add the light entities to the dynamic light system
- probably more i don't remember ;)
====== tlh2000 (2010-05-02 07:46:16) ======

btw. see base/ufos/entities.ufo for possible light and worldpsawn light flags
====== tlh2000 (2010-05-02 08:07:48) ======

applied coding guidelines, todo comments about floating point issues
====== tlh2000 (2010-05-02 09:19:45) ======

about the roughness maps and specularity maps - it would be nice if you could extend the wiki with this information and a guideline on how to create them. as much details as possible so artists can create good looking stuff (and with screenshots, step by step maybe). i will apply this to trunk soon - as it really looks a lot better than that what we have in trunk right now.
====== tlh2000 (2010-05-02 11:33:51) ======

i think we only have to call R_LightPointPosition in case we are not using the shaders, no?
====== tlh2000 (2010-05-02 11:34:50) ======

or maybe the whole static_lighting_t isn't needed in case of shader usage?
====== tlh2000 (2010-05-02 12:25:02) ======

ok, models.mk is done now - no more need for the shell script to generate the mdx files.
====== arisian (2010-05-02 12:47:44) ======

Thanks for taking a look at this. I tend to agree that the static_lighting_t thing shouldn't really be needed for the shaders with the new system, but I didn't want to break the old system until someone other than me had decided that the new system was good enough to replace it. I suppose having a separate branch for working on the renderer might be good, with the understanding that I don't actually want to "branch" the project so much as have a place that I can allow a small number of people to test my code without forcing it on everyone using the SVN. If you think that I should just push stuff like this directly to the trunk, I can; I guess I'm not sure just how "unstable" the trunk is allowed to be.

I'll take a look at your updated version of the patch today. I'll be sure to update the wiki with all the new texture info, as well. Oh, also, 'radiant' segfaults for me; does it work under linux for anyone else? Part of the trouble with integrating lighting in radiant with lighting in the game is that I don't have any idea what the lighting in radiant looks like, or how it works.
====== tlh2000 (2010-05-02 16:11:47) ======

i'm only using linux - and yes, radiant works here. lighting in radiant is not shown (no support for this in the renderer).
====== tlh2000 (2010-05-02 18:19:47) ======

i wonder whether r_dynamic_lights should be checked against rconfig.maxLights - to get the max supported hardware lights, as we are using GL_LIGHTX constants to get the data into the shaders. (my old ati card is refusing to compile the shaders again - but i'm still searching the reason)
====== arisian (2010-05-02 18:21:14) ======

Yes, it should; actually, it already does in my local version, I just forgot to do that until after I'd uploaded that giant patch, and it didn't seem worth uploading another version. Of course, if GL_MAX_LIGHTS reports more lights that your card can actually handle, then I don't know what to do about it other than say to lower the number of dynamic lights by hand.
====== tlh2000 (2010-05-02 18:23:08) ======

of course - that's something we have to put our trust in ;)
====== tlh2000 (2010-05-02 18:54:02) ======

removed static_lighting_t and related functions
====== tlh2000 (2010-05-02 18:54:22) ======

attached is a patch that removes the static_lighting_t stuff
====== tlh2000 (2010-05-02 19:24:21) ======

my old card still fails to compile the unrolled loops - maybe the array size?
====== arisian (2010-05-02 20:18:12) ======

The array size should be set to whatever value you have for r_dynamic_lights; there's an option for it at the bottom of the graphics menu. Have you tried making it smaller?
====== tlh2000 (2010-05-02 20:37:15) ======

i've added some comments in https://sourceforge.net/apps/trac/ufoai/changeset/29693/ about my ati x600 card - if you have any ideas why light_fs.glsl isn't compiling (see todo comment for the error line) - please let me know.
====== tlh2000 (2010-05-02 20:37:59) ======

...and about the array sizes - this works for me: https://sourceforge.net/apps/trac/ufoai/changeset/29691 - see the commit comment included.
====== arisian (2010-05-02 20:58:29) ======

Ahh, okay, glad you figured it out and fixed it. I'll keep that in mind for future shader code.
====== arisian (2010-05-03 01:07:28) ======

Your patch to remove static lighting works for me; I'd say go ahead and push it to the SVN.

Also, what error message do you get when you try to compile the shaders?
====== tlh2000 (2010-05-03 05:52:56) ======

static lighting is removed now - some fixes for the dynamic lights went into trunk, too - you have to keep in mind that in case of random map assemblies more than one map is loaded. each map has its own worldspawn entity (entity 0 - the very first one in every map) thus SP_worldspawn can be called more than once. that's why i've moved the R_ClearActiveLights call into CL_SpawnParseEntitystring (which is only called once)

i've also parsed the ambient light color settings from worldspawn - it might be a good idea to add the other light values to the worldspawn entity, too (entities.ufo) - that way mappers can controll the color values for each map as they want it to look (optional).
====== tlh2000 (2010-05-03 06:15:07) ======

another issue we should solve is that setting r_dynamic_lights to 0 results in shader compilation errors - either we have to ensure a min of 1 or we have to add sentinels to the shaders.
====== tlh2000 (2010-05-03 06:53:56) ======

oh and about the error message: "Shader not supported by HW" - that's all. no more details. that's why i'm removing line by line to see where the problem is. it also might be that there are too many variables, or too many statements, or too many functions. i don't know yet. i have to do some research to find out which limit exactly is the cause of this problem.
====== tlh2000 (2010-05-03 07:25:28) ======

btw. will we also get shadows once we have proper dyn lighting? ;)
====== arisian (2010-05-03 13:05:59) ======

The current code doesn't do shadows or occlusions, but those are certainly features I'd like to add eventually (in particular, actors will still be illuminated by the "sun" even when they're indoors with the current codebase). One feature at a time though ;)

The reason I added the R_ClearActiveLights was that if you don't do that you wind up with two "sun" sources, which makes everything twice as bright as it should be. I definitely think that we should add per-map lights; I had assumed that there was some set of light sources that was being used to render the deluxemaps and lightmaps for the BSP surfaces, and that we would just add those to the world. I'm still not 100% clear on how the deluxemaps are calculated, since I haven't gone digging in that code yet, but my impression is that there are no "global" light sources that get used to calculate BSP illumination, but rather each BSP has its own personal set of spotlights. If that's the case, it wouldn't make sense to add those spot-lights to the dynamic lighting system, since they wouldn't light other models the way you'd want anyway.

Ultimately, I'd really like to have one system that renders everything the same way; having separate lighting models for different types of objects is always going to look a little bit odd. I'm not opposed to having some off-line calculation of lighmaps for the occasional BSP that requires very complex lighting (for calculating shadows, in particular, this could be useful), but I think that the majority of the lighting should be done dynamically so that the actors and the scenery actually get illuminated by the same sources. I think this would also make the process of creating maps and BSPs easier, since you would only need to set up lights per-map, rather than per-BSP.
====== tlh2000 (2010-05-03 13:47:22) ======

well, we have three different types of lights:
* light entity - the mapper can place them everywhere and assign a color and a radius
* surface lights. Each bsp face can have a surface flag (SURF_LIGHT) assigned with a brightness value
* sun light (each map can define this in the worldspawn, if not, a default is taken by ufo2map for day/night versions to calculate the lightmap)

the first two can just be added as they come from the data. the sunlight should of course only be added once (even for rma [random map assembly]). it looks like it's currently added for every tile of the rma, no? (maybe due to my change).

lighting and shadowing everything dynamic would be very cool - destroying objects like func_breakables would look a lot cooler then. currently you can destroy a func_breakable and the "void" is still throwing shadows because it's statically baked in the lightmap.

here is the source that is responsible for the lightmap and parallax data.
/ufoai-trunk/src/tools/ufo2map/lightmap.c
/ufoai-trunk/src/tools/ufo2map/lighting.c
====== arisian (2010-05-03 13:53:38) ======

Yeah, being able to have objects get broken or removed and still look "right" is honestly a large part of the motivation behind trying to get everything to render the same way. Don't tell anyone, but I'm secretly trying to push the renderer in a direction that will eventually allow destructible environments ;)
====== tlh2000 (2010-05-03 17:25:40) ======

we really have to think about the format of the tangents and normals - the models pk3 is now ~430MB - which is a little bit too much ;)

ps. i won't tell anyone :D
====== tlh2000 (2010-05-03 17:27:18) ======

about the sizes... the "problem" is imo only the frames. do we really have to store the values for every frame? can't we somehow interpolate the values from the animation data?
====== arisian (2010-05-03 20:19:03) ======

I suspect we can; as I said, that code is currently not optimized. How are the animations encoded? Are the vertexes actually specified for every frame? That's what it looked like to me from the model-loading code, which is why I stored the tangents and normals on a per-vertex basis, which meant a copy for every frame. Honestly, storing the vertex locations for every frame seems like overkill to me; I would think it would make things smaller *and* make life easier for the modelers if we stored keyframes and interpolated vertex positions between them.

The best way to store things, in my opinion, would be as a set of initial vertex locations coupled with a time-varying transformation function that would specify how the vertexes, normals, and tangents should be transformed to get to the new frame. The transformations would probably be encoded as 4x4 homogenous matricies; each ridged body would would need one matrix per frame (or keyframe, either way).

Unless I misunderstand how the current system works, that type of animation description going to be easily compatible with the current ufoai code, so we probably can't use it. The difficulty with interpolating using the current method is that we need to handle both translations and rotations in order to keep the normal vectors aligned properly. It's easy enough to calculate a translation for a vertex relative to the original model, but calculating a rotation requires more than one point; it'll have to be done on a per-triangle basis, and I'm not sure off the top of my head how fast it will be.
====== arisian (2010-05-03 20:24:08) ======

Actually, there is another thing that could be done which would probably reduce the file size for the mdx files, and that would be to make sure that all the triangles in a model were drawn in the same order (either clockwise or counterclockwise relative to the normal vector). If a vertex is part of two triangles with different "handedness" (ie. is the tangent space left or right handed), then we have no choice but to store separate copies of the vertex, including the normals and tangent vectors. This is due to the fact that if you try to combine them, you get horrible artifacts where the tangents suddenly reverse directions; this issue is the reason I had to write new code to figure out which verticies needed to be considered "unique" before the tangent-space rendering looked right. If this problem occurred less frequently, it should automatically reduce the size of the mdx files.
====== tlh2000 (2010-05-03 20:57:53) ======

if we want stuff like ridged bodies - we should really use the dpm model format. It's the darkplaces model format - designed by LordHavoc, and used in darkplaces or (a little bit modified) in warsow. warsow was based on a q2 engine fork, too - so it might be a little bit easier to look into that codebase - see http://www.warsow.net/download/mirror.php?file=warsow_0.5_sdk.zip
====== tlh2000 (2010-05-03 20:59:10) ======

oh, and the darkplaces source is here: http://svn.icculus.org/twilight/trunk/darkplaces/
====== mcr2010 (2010-05-03 21:22:43) ======

I am sorry to interrupt here (once again ;)), but if we want this system to work we HAVE to take care also of this max_textures 1024 limit. If every property-texture, glowmap, roughnessmap & specularitymap is counted as texture we will not have much air to breathe from the artistic side - I was already experiencing this limit sometimes just with the frames for the ufo animations...
If we want to sell the player a future-tech city, that is somehow believable & looks great, we WILL need more than 1024 textures.

/offtopic on
@Mattn: Please do not modify the Taman-patch, but put it into trunk the way I designed it - it is perfectly working & we will have 16 possible different versions of unarmored Tamans being spawned in-game & the armored versions will also work ! I really do not know why you modified the patch ???
/offtopic off
====== mcr2010 (2010-05-03 21:24:25) ======

P.S.: I know. ;) But I won't tell anyone also.
====== mcr2010 (2010-05-03 21:31:36) ======

@arisian : Here the best md2 description I found. Was very useful for me, so I think it might be interesting if you want to know how exactly information is stored & handled when using the quake md2 format:

http://tfc.duke.free.fr/old/models/md2.htm

====== arisian (2010-05-04 00:51:27) ======

Okay, so far I've come up with two ways to do this. The first is to use a model format other than MD2 which specifies animations in a more friendly way. This would be faster at runtime, but would require the creation of a lot of new game resources, which to me means that it's probably not really worth considering. The second way will incur a higher runtime cost, but would work with our existing models, and should only require us to store tangent/normal vectors for the "base" verticies; for all the frames, we can just use the standard format.

Basically, we need to calculate a rotation matrix for each triangle at each frame. We can't pre-compute and store them, because that would be just as expensive as storing the normal/tangent vectors. Generating them on the CPU at runtime is going to be too expensive. What we can do, I think, is to generate them on-the-fly in the vertex shader; the massive parallelism should (I hope) be enough to avoid massive slowdowns. Since I'll need to do interpolation anyway, I think it makes the most sense to move all the LERPing into the vertex shader as well, since again it will be a lot faster there (and hopefully that will make up for some of the speed we'll loose by calculating the per-vertex rotations on the fly). It will, however, require the use of at least two more vertex shader ATTRIBUTE variables than are currently in use. I've committed a small patch so that r_main.c now gets GL_MAX_VERTEX_ATTRIBUTES and prints the value, as well as storing it in a r_config variable. Mattn, could you tell me what the max it lists is on your system? I don't want to spend too much time on this idea if it's not going to work on older cards.
====== tlh2000 (2010-05-04 11:05:29) ======

max vertex attributes: 16
====== arisian (2010-05-04 12:46:08) ======

Ahh, good; that will be plenty :)
====== tlh2000 (2010-05-05 06:42:46) ======

that's how +africa currently looks for me
====== tlh2000 (2010-05-05 06:43:19) ======

attached a screenshot of how it currently looks for me - why is it so bright? due to several suns we might add in case of random map assembly?
====== arisian (2010-05-05 13:41:54) ======

Yes, the issue is that lights are getting added multiple times without the active light list being "cleared" inbetween. All the active lights in a scene get applied, so their brightness is effectively summed if they're in
the same position (which all the "sun" sources are). It's not really an issue with the rendering, it's an issue of
how we're generating/loading the light sources.
====== tlh2000 (2010-05-05 18:33:06) ======

about the space that is used: have you ever tried to store the tangents in an image?

i would say this would be a nice option, too, no? would also reduce the amount of code that would be needed in order to load and use them.
====== tlh2000 (2010-05-05 18:57:59) ======

the brightness is fixed in r29765
====== tlh2000 (2010-05-06 18:09:52) ======

the mdx files results in a 338 MB bigger 0models.pk3 file !! wow. that's something we have to work around before we release ;)

it was 111mb before mdx and is 449 after adding them - highest zip compression
====== arisian (2010-05-06 21:15:48) ======

I'm still working on the tangents; the MDX files will be a lot smaller by the time I'm done, I promise. I'm not sure when it'll be done, since I've been banging my head against some strange bugs for the last few days that I haven't been able to figure out, but I am actively working on improving the way that the normal/tangents are generated, stored, and used.
====== arisian (2010-05-08 02:33:15) ======

moved LERPing for animations into GLSL, mostly-working on-the-fly normal/tangent code
====== arisian (2010-05-08 02:37:50) ======

I've just attached a patch based on my current working codebase. It's a bit of a mess at the moment, and has several things that are only useful for testing (eg. the GLSL has been modified so that it renders the normal vectors dotted with the light vectors so that you can actually see whether the normals are smooth and correct or not). I'm still having some issues with trying to generate normals and tangents on the fly for all but the first frame for a given mesh; there's code in there now (disabled in the patch, but easy to switch to by changing a "#if 1" to "#if 0" in R_FillArrayData) which gives vectors that are close, but not quite perfect, and I haven't been able to figure out why. If you have any time to take a look at the R_RotateNormals() function and see if you can figure out why there are small errors, that would be great; otherwise, I'll keep working on it. Once we get that function working, we should be able to only store the normals and tangents for the very first frame of data for each model, which should reduce the size of the MDX files a lot.
====== tlh2000 (2010-05-08 07:11:50) ======

about the threading of the renderer, we already have that - see cvar r_threads

about the glsl shaders for rendering the normals. please don't remove that in your final patch but make it switchable with a cvar of the type CVAR_R_PROGRAMS - something like r_render_normals and add an #if r_render_normals into the shaders. that's a great feature for debugging normals
====== arisian (2010-05-09 00:19:07) ======

Okay, I think I've got something that works now. There are still some optimizations that should be made at some point, but they shouldn't change functionality, just slightly increase framerates. I've committed the new tangent/normal/MDX code in r29793; I've tried to test it with GLSL both on and off as well as I could, but do let me know if you run into any issues. You should also delete the old MDX files and generate new ones; the new format is *much* smaller.
====== tlh2000 (2010-05-09 06:07:12) ======

did you maybe forgot to commit lerp_*.glsl? it's referenced at least twice in the glsl code but i can't find it.
====== tlh2000 (2010-05-09 06:15:06) ======

mattn@mattn-desktop:~/dev/ufoai/trunk$ gdb ufomodel
GNU gdb (GDB) 7.1-ubuntu
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/mattn/dev/ufoai/trunk/ufomodel...done.
(gdb) run -mdx
Starting program: /home/mattn/dev/ufoai/trunk/ufomodel -mdx
[Thread debugging using libthread_db enabled]
---- ufomodel 0.2 ----

---- filesystem initialization -----
Adding game dir: /usr/local/share/ufoai/base
Adding game dir: /home/mattn/.ufoai/2.3-dev/base
Adding game dir: ./base
using ./base for writing
- model &#039;models/pilots/male/body.md2&#039;
\ - mdx already exists
- model &#039;models/pilots/male/head01.md2&#039;

Program received signal SIGSEGV, Segmentation fault.
0x0000000000417fc3 in R_ModCalcNormalsAndTangents (mesh=0x295da98, framenum=0, translate=0x295f910, backlerp=qtrue) at src/client/renderer/r_model_alias.c:160
160 const int len = mesh->revIndexes[i].length;
(gdb) bt
#0 0x0000000000417fc3 in R_ModCalcNormalsAndTangents (mesh=0x295da98, framenum=0, translate=0x295f910, backlerp=qtrue) at src/client/renderer/r_model_alias.c:160
#1 0x000000000041d0df in R_FillArrayData (mod=0x295d940, mesh=0x295da98, backlerp=0, framenum=0, oldframenum=0, prerender=qtrue) at src/client/renderer/r_model_alias.c:570
#2 0x000000000041d706 in _R_ModLoadArrayDataForStaticModel (mod=0x295d940, mesh=0x295da98, loadNormals=qfalse) at src/client/renderer/r_model_alias.c:622
#3 0x0000000000421a88 in R_ModLoadAliasMD2Model (mod=0x295d7a8, buffer=0x29941b8 "IDP2\b", bufSize=31976, loadNormals=qfalse) at src/client/renderer/r_model_md2.c:524
#4 0x0000000000406b9f in LoadModel (name=0x295fb58 "models/pilots/male/head01.md2") at src/tools/ufomodel/ufomodel.c:210
#5 0x0000000000406edf in PrecalcNormalsAndTangents (filename=0x295fb58 "models/pilots/male/head01.md2") at src/tools/ufomodel/ufomodel.c:283
#6 0x0000000000407008 in PrecalcNormalsAndTangentsBatch (pattern=0x425367 "**.md2") at src/tools/ufomodel/ufomodel.c:313
#7 0x0000000000407e33 in main (argc=2, argv=0x7fffffffe318) at src/tools/ufomodel/ufomodel.c:624

====== tlh2000 (2010-05-09 06:34:59) ======

not sure whether these are all errors due to the missing lerp_*.glsl file(s) - but anyway - here some warnings and errors

Failed to resolve #include: shaders/lerp_vs.glsl.
R_LoadShader: world_vs.glsl: 0(52) : error C1008: undefined variable "Normal"
0(53) : error C1008: undefined variable "Vertex"
0(74) : error C1008: undefined variable "Tangent"
0(76) : error C1008: undefined variable "Tangent"
0(152) : error C1008: undefined variable "lerpVertex"
0(155) : error C1008: undefined variable "Vertex"
0(156) : error C1008: undefined variable "Normal"
0(157) : error C1008: undefined variable "Tangent"
0(157) : error C1008: undefined variable "TANGENTS"
0(162) : error C1008: undefined variable "Vertex"

R_LoadProgram: world: Fragment info
-------------
0(262) : warning C7050: "R_2" might be used before being initialized
0(262) : warning C7050: "NdotV" might be used before being initialized


====== tlh2000 (2010-05-09 06:36:03) ======

also looks like the warnings about slow calculation of mdx can be removed now :-D - great job

btw. it would be cool if you could add doxygen to the functions you are creating.
====== arisian (2010-05-09 13:17:07) ======

Sorry about that, lerp_vs.glsl is in the repository now; I forgot to add it before doing my commit last night. As for the ufomodel segfault, try deleting all the MDX files before you run it. And I&#039;ll document my code, I just haven&#039;t been doing it as I go because I keep changing things. Now that I have a version that works, I&#039;ll go back and document it; I just wanted to get the working code into the SVN so people could start playing with it/finding bugs.
====== mcr2010 (2010-05-09 13:31:35) ======

I forgot to mention: GREAT WORK !
The rendering is very smooth, it is really great to see such improvement going on here.
Please give us a wink when we will be able to start testing all the new maps ;)
btw, is normalmapping for models enabled @ the moment ?
====== arisian (2010-05-09 13:33:34) ======

Yes, normalmapping is enabled. I&#039;ll warn you, though, some of the normal-maps you posted to the forum a while back are badly formed, and will look very strange in-game if you haven&#039;t fixed them in the mean time. Specular maps and Roughness maps are also enabled; see the "Textures" page on the wiki for details on those.
====== arisian (2010-05-18 02:44:52) ======

New rendering features from this point forward are going to be in a new branch "renderer_work", which should be a lot easier than posting giant patches to the tracker. That branch currently contains my work-in-progress realtime-shadow code, which basically works, but has a lot of ugly aliasing artifacts that I need to find ways of avoiding or correcting. If you want to discuss those features, we should start a new topic.