Jump to content
The Dark Mod Forums

greebo

Root
  • Posts

    16732
  • Joined

  • Days Won

    50

Everything posted by greebo

  1. No, the changes should and will only affect brushes that have duplicated planes on them, which can happen only when loading legacy maps. DR never created or saved brushes like this. I didn't even know that this was possible until I encountered this brush in alphalabs. It's also curious that DoomEdit doesn't correct the problematic faces when changing or saving the map (it continues to complain about it when manipulating the brush), so it just preserves the duplicated planes. It's relying on the engine code to weed them out during dmap.
  2. When loading that brush, DoomEdit just spits out this in the console and continues: The game loader deals with brushes on several occasions, for instance the dmap code will send another warning, removing the second duplicate: if ( sides[i].planenum == sides[j].planenum ) { common->Printf("Entity %i, Brush %i: duplicate plane\n", b->entitynum, b->brushnum); // remove the second duplicate for ( k = i + 1 ; k < b->numsides ; k++ ) { sides[k-1] = sides[k]; } b->numsides--; i--; break; } DarkRadiant's brush BREP code will reject the brush, and the code doing that is very old, I'm pretty sure it has already been in place when we forked GtkRadiant. I'll try to adjust DarkRadiant to not remove the brush and to treat it the same way as the game code.
  3. Yes, I can confirm the problem in alphalabs1.map, the brush that is missing in this screenshot is primitive 9447. It is a brush with 9 faces, but 3 of these face planes are redundant. Obviously the brushDef3 is still valid for DoomEdit, but DR regards it as degenerate. I'll see what I can do.
  4. I'll try to check it out some time, I have to find the D3 files first. I'll create a bugtracker entry: https://bugs.thedarkmod.com/view.php?id=5942
  5. It's been over a decade since I last tried to open a vanilla map, but it used to work. I don't even have the original game PK4s at hand anymore on this laptop, I'm afraid I can't even test this here. Is there anything written in the console about missing resources or similar? Are the project settings defined correctly?
  6. A new 3.0.0pre3 build is available with a couple of fixes, see first post.
  7. I just tried with MFA enabled on my own Github account. It doesn't prompt me for anything whatsoever, I assume that's because the locally stored auth token is sufficient for pushing content. It's difficult to see what's going on between git and the remote server without debugging or seeing the network traffic. Not sure if I can do anything here. Do you happen to have a gitlab repository, perhaps, to see if it's working for you there?
  8. I am familiar with this problem, but I haven't been able to track it down. It definitely has to be fixed before release, it's corrupting the view. I assume it's a problem in the synchronisation code that is managing the geometry data stored in the GPU buffer. At some point, things can go out of sync and those stretched geometry appears - it disappears once the map is reloaded. Everytime of the few times it happened on me, I tried to repro it but I failed, so if anybody can give me any insight on repro steps, I'd be grateful.
  9. Ambient lights are working now, this will be part of the next pre3 build.
  10. Can you please show me the log file when that happens? Maybe I can spot something.
  11. I downloaded Down by the Riverside and had King of Diamonds downloaded earlier, opening these maps to reproduce the problem. I tried with my recent build and with the pre2, and while DR does eat a lot of RAM (it shows 5.6 GB in Task Manager) when switching to lighting mode and shadows turned on, it stays that way and doesn't kill the process. Memory figures stay at 5.6 GB wherever I fly around in the level, regardless whether I'm in lighting mode or the regular fullbright mode. Can somebody confirm / try doing the same? Open DR pre2 with the project setup pointing to "river" or "kingofdiamonds". Then File > Open Map from Project... and pick the kod.map or the river.map, respectively. When moving around 3D view it stutters a bit as new things come into view, RAM is increasing, but as soon as DR has "seen" everything, memory consumption should stay constant at about 5-6 GB (at least for me).
  12. While some lags when zooming out and bringing previously unrendered things into view might be explicable, it shouldn't eat up your RAM completely, so this sounds rather severe. I'll try to look into that.
  13. Usually Git for Windows will store the credentials of the remote in the windows credential store, something like git:https://github.com. If DR can find that entry, it will use the credentials from there. But maybe your git client is not storing anything in there? Anyways, the authentication entry box needs to be implemented some day.
  14. Are you on Linux? I haven't looked into authentication matters in Linux. In Windows, DarkRadiant will take the credentials stored in Windows' Password Store, so git can authenticate against the remote. I was meaning to add some entry box to support entering the credentials, but I haven't got around to do so.
  15. New 3.0.0pre2 build is available in the first post.
  16. It's sometimes not enough to set the alpha value on the vertices, the shader used to render them needs to support it. The SpeakerNode is using the default EntityNode::_fillShader to render its geometry, but the fill shader is not supporting alpha. The fill shader is requested in EntityNode.cpp:448: _fillShader = renderSystem->capture(ColourShaderType::CameraSolid, colour); The CameraSolid type is not supporting alpha. You can try to use the EntityNode::getColourShader() in SpeakerNode::onPreRender instead of getFillShader(), maybe the alpha values will be respected then.
  17. It's surely possible to make them translucent, of course. You won't know until you try, so feel free to have a go at it.
  18. Depends on whether it's useful or not It's just the first thing I got working when migrating the renderable objects.
  19. In DR up to and including 2.14 this is not possible, without hacking the code that is. In DR 3+ these diamonds are not rendered at all, among a lot of other meta-things like selection highlights, entity arrows, path connectors, etc.
  20. @OrbWeaver unit tests should be working again in Linux, at least they're not immediately crashing anymore. There's a lot of features that DR doesn't support yet. I added shadows, but that's not the same as supporting all the possible material keywords, there's a lot of ground to cover here. Shadow mapping != stencil shadows. Vanilla Doom 3 is using stencil shadows, which is operating on object silhouettes only, if I'm not mistaken, therefore no alpha-tested shadows. I didn't want to port two shadow rendering modes, so I settled for shadow mapping, which do support alpha-tested materials. Doesn't mean it's impossible to implement stencil shadows at some point, since TDM can do both simultaneously. At least it's nice to hear that projected lights are even working, I haven't tested them and would have assumed that they were entirely broken. I have no clue yet about the lights being too dim or even missing, maybe there's also a difference in light handling between TDM and vanilla Doom 3? I really modeled the render code after the current TDM implementation, maybe that's the reason.
  21. This really depends on how the entityDefs are set up. Can you show an example of where the anim property is expected to show up?
  22. The brightness and the z-fighting problems seem to be something to look into. It's entirely possible that projected lights aren't working at all, I spent time on point lights only. Cubemap reflections have never worked in DR so far, the GLSL code in the cubemap shader code is lacking the reflection part. But I saw it in the TDM shaders, I think this is not too hard to get it working in DR. What are alphablend materials? Generally, I'd appreciate test maps or test PK4s and/or bug tracker entries, this increases the chances of these things getting fixed.
  23. Hm, seems to be more involved then. Thanks for investigating that.
  24. Yes, it's the GL buffers being destroyed too late during shutdown. They are held by the GeometryStore and this one has to be destroyed in shutdownModule(), I assume. Can you file a bug entry, please? I'm going to fix it over the weekend.
×
×
  • Create New...