greebo
-
Posts
16733 -
Joined
-
Days Won
51
Posts posted by greebo
-
-
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.
-
1
-
-
When loading that brush, DoomEdit just spits out this in the console and continues:
QuoteUnable to create face winding on brush
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.
-
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.
Quote// primitive 9447
{
brushDef3
{
( 0 0 1 -128 ) ( ( 0.015625 0 -14 ) ( 0 0.0078130001 0.7460148931 ) ) "textures/base_wall/gotcgate" 0 0 0
( 0 1 0 -4144 ) ( ( 0.015625 0 -1.5000076294 ) ( 0 0.0078119999 -0.9999359846 ) ) "textures/base_wall/gotcgate" 0 0 0
( -1 0 0 -136 ) ( ( 0.015625 0 14 ) ( 0 0.0078130001 -1.0000640154 ) ) "textures/base_wall/gotcgate" 0 0 0
( 0 -1 0 4104 ) ( ( 0.03125 0 0 ) ( 0 0.03125 0 ) ) "textures/common/caulk" 0 0 0
( 1 0 0 128 ) ( ( 0.015625 0 0 ) ( 0 0.0078125 0 ) ) "textures/base_wall/gotcgate" 0 0 0
( 0 0 -1 -128 ) ( ( 0.015625 0 -14 ) ( 0 0.0078130001 -0.7460148931 ) ) "textures/base_wall/gotcgate" 0 0 0
( -1 0 0 -136 ) ( ( 0.0104219997 0 43.905040741 ) ( 0 0.0078130001 0.9999360442 ) ) "textures/base_wall/gotcgate2" 0 0 0
( 1 0 0 128 ) ( ( 0.015625 0 -14 ) ( 0 0.0078130001 -1.0000640154 ) ) "textures/base_wall/gotcgate" 0 0 0
( 0 1 0 -4144 ) ( ( 0.015625 0 -1.5000076294 ) ( 0 0.0078119999 -0.9999359846 ) ) "textures/base_wall/gotcgate" 0 0 0
}
} -
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
-
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?
-
A new 3.0.0pre3 build is available with a couple of fixes, see first post.
-
1
-
-
On 4/10/2022 at 11:43 AM, Frost_Salamander said:
I just had a thought. I have MFA enabled on my Github account - maybe it's something to do with that? It's not an issue though with other tools that I use for this. With either VS Code or command line I can push fine and there aren't any more prompts.
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?
-
On 4/11/2022 at 8:01 AM, LDAsh said:
There were these infinitely stretched pieces of geometry flying through everything, that only appear on certain view-angles, I only ever saw that stuff with GPU glitches, like heat-death. Something is very wrong.
On 4/11/2022 at 1:34 PM, jonri said:It turns out my map has 2 func_static beams that go missing and turn into something like this down at one end of my map. I haven't had a chance to look into it further, but I can confirm there's an issue. Mine didn't crash though.
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.
-
19 hours ago, jonri said:
I think at least part of the problem might be related to ambient lights. I built a quick little test map, and it seems like ambient lights are treated like any other point light. Instead of providing even lighting, they are illuminating surfaces according to their normal and have a falloff.
Ambient lights are working now, this will be part of the next pre3 build.
-
12 hours ago, Frost_Salamander said:
Hmm the credential seems to be there:
Can you please show me the log file when that happens? Maybe I can spot something.
-
13 hours ago, Spooks said:
I'm still on Windows 7 per my mantis bug reports. I'm also using the portable versions to test, if that helps any. I opened Down by the Riverside's river.map ("from Project") to test out the new lighting preview mode with DR 3 earlier in the week. It also lagged like hell but mainly due to zooming out the orthoview, not so much flying around. I thought that might be normal, not my map, right, so I ignored it then. DR does die pretty quickly when I'm zooming out in King of Diamonds' kod.map and there I'd definitely know if something is out of the ordinary.
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).
-
31 minutes ago, Spooks said:
Worse yet, zooming out the orthoview stuttered like hell and the RAM usage quickly spiked up to the max 6 GB my system has. Bam, computer freezes, have to push the reset button with a paperclip.
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.
-
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.
-
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.
-
New 3.0.0pre2 build is available in the first post.
-
1
-
-
1 hour ago, jonri said:
I tried to set the alpha on the colour variable in RenderableSpeakerRadiiFill::generateSphereVertices but it didn't seem to have any effect. @greeboany idea why that one would be different? At a first glance, the rendering code looked very similar for the light and speaker gizmos.
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.
-
1
-
-
3 hours ago, jonri said:
Making them solid but translucent might be a nice compromise, although you wouldn't see the true color of the light any more. Same with the sound sphere, but without the downside. Would this be hard for me to try myself?
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.
-
1 hour ago, jonri said:
I've noticed that light and sound markers are now opaque, is this a bug or a feature?
Depends on whether it's useful or not
It's just the first thing I got working when migrating the renderable objects.
-
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.
-
@OrbWeaver unit tests should be working again in Linux, at least they're not immediately crashing anymore.
21 minutes ago, LDAsh said:I also noticed that the 'common/shadow' materials don't cast shadows. This doesn't explain why maps loaded wholesale seem darker, as if every second light is missing. If anything they should be brighter with more light.
I also noticed that alphatested materials cast shadows of their alphas. This is really cool, despite not being engine-accurate? At least, I don't remember vanilla Doom3 being able to do this. Again, it would explain brighter results, not darker.
'No_diffuse' flag on lights doesn't seem to work, nor does 'no_specular' or 'parallel', but I don't recall ever using those anyway.
It's possible that parallel lights were used a lot and they are now just rendering as projected lights and not "filling-out" as much as they otherwise would? Just a guess.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.
-
1
-
-
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?
-
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.
-
Hm, seems to be more involved then. Thanks for investigating that.
-
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.
Opening Doom 3 maps with DarkRadiant?
in DarkRadiant Feedback and Development
Posted
Problem is solved in source, the next pre-release build will include that fix.