greebo

This could be a hard nut, because when middle-clicking into the scene, you select a face as a whole (determined by line selection tests). I don't know if would be possible to get the nearest winding vertex of the selected brush face. If it was possible, the vertex could well be stored for later reference, although I fear that this would become a bit wacky if you're unaware of that feature - it may appear that the texturing may be irreproducible because one might never click on the same place. Ok, never used this before, I think it should be possible to do, so I'll assign this to myself.

As reported by SneaksieDave here: http://bugs.angua.at/view.php?id=79 I couldn't come up with any fine name so far, I use to call it "Paste Natural" (Shift-MMB) in contrast to "Paste Projected" (Ctrl-MMB) I just tested and could reproduce it on the second patch, so I see what you mean. I have some things to post here, so thanks for reading it in advance The Paste Natural thing is probably not the right tool here. It's designed to make the transition of patches and brush faces seamless. Aren't you better off with the "NATURAL" button in the Patch Inspector? For these arches, the transition from the floor to the wall wouldn't have to be seamless, would it? You have only limited influence on how the texture is pasted via Shift-MMB. The rotation or matrix inversion does not have an effect, but the position has. I'll better explain how DarkRadiant is working: The Paste Natural searches for the nearest patch vertices to the originating brush (where you copied your texture from) and "rolls" the texture onto the patch from the nearest to the farthest control vertex. Therefore the rotation of your patch should not have any influence on the texture orientation. To illustrate: I created two patches (both adjacent to a brush face) and rotated one of them. After copying the texture from the "floor" brush and pasting them via Shift-MMB the result looks like shown in the left picture. The texturing is identical, although the right patch has been rotated for 180 degrees (for this reason I showed the control vertices, so it's obvious how they were rotated). The shortest distance is determined like this: The "Paste" command searches for the shortest distance of any brush winding vertex to any patch vertex. Hence it does matter how far the patch is away from the face corners. In the picture the rightmost patch is being textured using the rightmost face corner as reference point, the left one has a different reference vertex. This is intentional behaviour, because the Paste Natural command has been designed for patch / face transitions, not for the kind of situations I just described here. (I'm not quite happy with this explanation yet, so please tell me if I should explain something in more detail.)

Ah, seems to be there is some room for improvement here. If you hold down any of the modifiers (Ctrl, Alt, Shift), there should appear some context help in the lower left corner in the status bar. I can't remember if this feature made it into 0.8.1, however, so maybe it isn't there in your release. Apart from that, I could imagine that the Wiki would be a place to store some information like that. What would you suggest?

There is the "suspended" status, maybe this fits. I'll set it to something meaningful.

Yes, that pretty much sums it up. I already looked at the tesselation code, and it definitely sounds not fun. There are a few hundred lines, completely undocumented, of course with recursions. If I was to investigate this, I'm sure it will take me a month to disassemble it. I'm not afraid of the math (I've seen a lot of it in my life, believe me), but this is probably only maintainable for the one that wrote it.

I just checked how Doom3 handles patches, and it seems to be the same way as DoomEdit does. I still don't think this is a major problem. Don't get me wrong, it would be nice if the tesselation was the same, but I doubt that this can be easily fixed. Tesselation is not quite trivial and I wouldn't want to reverse-engineer that one. I don't want to sound destructive though, if everyone else agrees that this is some serious problem I can look into it. No, you're right, only the vertices get saved for patchDef2.

SneaksieDave, this is not the patch from the map you submitted to FTP. In this example there is a patchDef3, which has fixed tesselation. This patch should be tesselated in the same way in both editors. Can you send me this map as well so that I can check it?

Now which map are we exactly speaking about? This is the patch definition from the arch you uploaded: patchDef2 { "textures/darkmod/stone/floor/tiled_001" ( 3 3 0 0 0 ) ( ( ( -132.0000152588 -734.8048095703 72.6638641357 0 0 ) ( -144.0000152588 -734.8048095703 72.6638641357 0 0.046875 ) ( -156 -734.8048095703 72.6638641357 0 0.09375 ) ) ( ( -131.9999847412 -709.3229980469 157.5072631836 0.25 0 ) ( -144 -709.3229980469 157.5072784424 0.25 0.046875 ) ( -156 -709.3229980469 157.5072784424 0.25 0.09375 ) ) ( ( -131.9999847412 -608 160 0.75 0 ) ( -143.9999847412 -608 160 0.75 0.046875 ) ( -155.9999847412 -608 160 0.75 0.09375 ) ) ) } The important part of this patchDef2 is the ( 3 3 0 0 0 ) after the texture name, which contains the matrix dimensions (3x3 in this case and three numbers that are (ignored) flags and are zero anyway. There is no indication on how the patch should be tesselated, that is obviously subject to the code implementation. DoomEdit obviously handles it differently than DarkRadiant does. The question is: is it possible to find out how Doom handles patches (how many subdivisions, etc.)? I will fire up Doom 3 and see what I might find.

phew, thought I screwed something up again. Ok, back to the shaders module!

I can't reproduce it, maybe I should install Ubuntu again... One thing I added was the ShaderLibrary along with some methods. Its results aren't used at the moment, although there are some calls to it in shaders.cpp::Try_Shader_ForName(). Maybe these corrupt something, but I couldn't say why this would be the case. I can comment out these calls if you want me to and commit them.

Ok, my build seems to work, but I'll try to look into it. (I changed the Texture* pointers to boost::shared_ptr yesterday, I don't think I changed the shader, but it's most probably related to it.) Edit: Oh boy, another HashedCache (I just checked, this is one of the two last instances). Edit2:If m_shader was invalid or NULL, how could the texture be retrieved in the first place? There is another access of m_shader two statements before the crashing one.

Well, it may be possible to introduce a preference regarding that option ("Use fixed tesselation for newly created patches" or something like that). If you feel that this is an important feature, please add it to the Bugtracker.

I think I screwed up the Overlay image handling by introducing the TexturePtr, so it's not possible to change the background image (possibly because the TexturePtr are not properly released). I will look into it soon.

Ok, I need some more information than that . When does it happen? During startup or shutdown? What did you before this occurred? Is it reproducible?

You can't create a patch lower than 3x3. It refers to the dimension of the control vertices array and as far as I know (I just tested it in DR), you cannot decimate a 3x3 patch any more by deleting it's rows or columns. I guess you're referring to the visible tesselation lines? That are indeed created automatic, and maybe you can gain a bit of performance by saving a few triangles. However, I would not want to have a fixed tesselation on every single patch that I create, because the optimal tesselation can only be defined after the patch geometry is done (bending, scaling, vertex stretching).

Basically, yes. There is no guarantee for the patches to align correctly in both editors. Still, it may be that Doom3 tesselates in yet another way, this had to be tested. If the DoomEdit source is ever being released, we could have a look at the tesselation code and "correct" the one in DarkRadiant (although I don't think that DarkRadiant is doing anything seriously wrong here). You're serious?

I'd prefer no fixed tesselation by default, because I would have to increase it manually when making the patch larger or drag its vertices around. It's far less flexible and won't look good in larger patches. The only cases where this is important is when aligning patches to each other (like in this archway) - and there it's always possible to turn it on when needed. I wouldn't call it a serious defect as long as we don't know how the Doom3 engine tesselates the patches. If sparklies appear in-game, you can always turn on the fixed tesselation.

As reported by SneaksieDave here: http://bugs.angua.at/view.php?id=77 Obviously the tesselation algorithm in DoomEdit and DarkRadiant is not the same, resulting in different patch subdivisions for the very same patch control vertices. I don't know if there exist "rules" about this, but if you ever need to solve such a problem (which may not only occur when switching editors), be sure to keep this option in mind: By opening the Patch Inspector (Shift-S by default), choose Fixed Tesselation for your adjacent patches, this forces DarkRadiant to take a fixed number of subdivisions, so all the virtual corners are aligned properly. (This will convert the patch from a patchdef2 into a patchdef3 for those who want to know how these are saved in the .map file).

Confirmed. I opened an issue in the Bugtracker - don't know how easy this is to fix, but I can look into it. (However, I personally don't like the splitplane view, but that's a matter of taste really)

Yes, that's "normal" for the moment being, till the material and def files are cleaned up. There is already an issue opened in the Bugtracker, so hopefully this will be solved in the near future.

Thanks, Komag!

Does Doom3 complain about being unable to load any textures when starting the map in the console?

No, they're just there in case you don't want to set the parameters directly and not via the RegistryKeys. It's your choice if you want to keep or remove them.

Aye, sir! Will put this on the Wiki as the system is growing, because it may change during development.

Ok, I think I can work with that one, I updated the diagram yet again (mostly for myself so that I don't forget the relationships )