jonri
-
Posts
190 -
Joined
-
Last visited
-
Days Won
15
Posts posted by jonri
-
-
On 11/5/2024 at 9:26 PM, MirceaKitsune said:
I have an interesting question: Do we have a setting to not render a model if its origin point isn't located in an open visportal, even if its bounding box intersects a room the player can see? If not can you associate the visibility of an entity with a particular info_location so it only renders in that area?
The reason why I ask: The building modules are pretty terrific visually speaking, but were made with some design issues when it comes to origin points and proportions. Often times you'll have an interior module poking outside, or oppositely an exterior module poking the interior of a room. You usually can't see them but the model is still loaded which will may decrease performance. It might improve FPS with the modules if interior and exterior walls can be bound to only render inside or outside, being completely derendered when the room they're bound to isn't open.
It sounds like you're looking for this: https://wiki.thedarkmod.com/index.php?title=Performance:_Essential_Must-Knows#AreaLock_(New_in_2.08)
Seems it was originally designed to constrain lights and particles, but I've used it on a couple large models in the same circumstances you've come across.
-
1
-
-
Congratulations to everyone who completed their FMs! Real life blew up on me again the last 2 months, but I'll be getting back to it in December. Here's to another 15 years of TDM
-
4
-
-
On 7/4/2024 at 1:30 PM, Frost_Salamander said:
I brought this up in Discord the other day. Apparently it's something to do with the origin of the models, so any fix would have to NOT change the models themselves. I will raise an issue for it.
Quotenote the model rotates back so it's facing away from you again and you need to rotate it again to see the new skin.
@datiswous@Frost_Salamander, would simply preserving the rotation rather than resetting it be an acceptable fix? I don't think that would be too hard to do. Different models consider different orientations to be the "front" so it would be much harder to try to automatically determine an optimal view for each model.
-
7 minutes ago, datiswous said:
This might also be possible via a script/plugin inside DR.
This should definitely be possible. The python scripting API has functions to loop through entities and read their spawnargs, and then you could use standard python file functions to write the EFX file.
It would be cool to have a proper EFX editor in DR, but writing a script would be a lot less work.
@Frost_Salamander if you decide to write a script like this I'd be happy to help you out if you get stuck. You can check out count_loot.py for a minimal example of looping through entities.
-
4
-
-
2 hours ago, MirceaKitsune said:
It could also be that on Linux we have to compile DarkRadiant ourselves, which means it's being compiled against newer versions of packages (GTK, WxWidgets, etc) and a slightly different configuration overall.
Is not quite that, but more likely because wx uses native Windows controls there and gtk only on Linux. It does a pretty good job of abstracting away the differences but there are always corner cases where a subtle difference turns out to be important.
-
14 minutes ago, datiswous said:
Why does it not crash on Windows though? Or is that code different there?
I'm honestly not sure, it's a race condition maybe? I found and fixed 2 different segfaults (PR is here), one relating to threading and the other one relating to a variable being referenced after it was cleared out. This stops the skin editor from crashing, but it seems there are still a lot of usability issues. I'm not sure if they are all Linux only, but here's what I found:
- The rename operation happens every time you type a character, which is a little laggy. It would be better to rename it when you are done typing and the field loses focus
- Typing new characters while renaming works as expected, but deleting characters causes the box to highlight so you have to reset the cursor before deleting another one.
- On the Material Replacements tab, click to edit is not working for me. I spent a lot of time on this, I can get a box to show up if I replace the editbox+button with a simple edit box. I think it's related to the compound control not being able to have focus.
- The skin name is showing up on top of the Close button
This will require more wxWidget-fu than I have time to do right now.
-
1
-
1
-
Looking at the backtrace and the code, I think the culprit is here: https://github.com/codereader/DarkRadiant/blob/fa4c266a6776516b59740f78f57b849097d97618/radiant/ui/skin/SkinEditorTreeView.cpp#L44
The ThreadedDeclarationTreePopulator is created on the stack and thus deallocated at the end of the function. The EnsureStopped() function is called on deletion (https://github.com/codereader/DarkRadiant/blob/master/libs/wxutil/dataview/ThreadedResourceTreePopulator.cpp#L108) but this doesn't appear to actually wait for the deletion to finish. By the time the deletion request is processed, the object itself is no longer valid. Other usages I see put the object in a shared pointer instead of on the stack.
I'll have a chance to look at this properly on Sunday and figure out the best way to fix it.
-
2
-
-
I think the devs just haven't had much time to put into it the past year (myself included). I took care of the mouse issue finally, since it became a 100% showstopper for me to use DarkRadiant at all on Linux. I've only ever made my skins using a text editor, but I tried reproducing the issue and it crashes with a backtrace for me too. This means debugging it should be straightforward, I'll look at it this weekend.
-
1
-
-
I've made a PR with some fixes required to release the Flatpak version, including a fix for the version number in CMakeLists.txt.
I've pushed the updates to flathub, so the new version should show up there once their scripts pick it up.
-
1
-
-
- Popular Post
- Popular Post
I'm in, using this as motivation to continue the work I had previously started on my series. Probably not a whole lot in the way of horror, but I think I have some creative elements in the pipeline...
-
7
-
In case anyone decides to pursue this further, here are a couple more references:
https://discourse.gnome.org/t/pointer-warping-on-wayland/9197https://gitlab.freedesktop.org/wayland/wayland-protocols/-/issues/158
Seems like this feature is also common in PCB design software. The "correct" solution would be to use Wayland's pointer locking interface and relative mouse events, which is essentially what the FreezePointer class accomplishes by continuously warping the pointer back to its original location.
The complication is that the way it works now all goes through wxwidgets which then goes through gtk3 on Linux. To fully implement this, I think someone would have to:
- Create a platform-specific alternative to the cross-platform FreezePointer that we have now
- Make sure it's only called on Wayland, and only if the pointer locking API is available
- Work your way through the wxwidgets / gtk3 layers to get hold of the native wayland surface and pointer handles
- Reconcile the Wayland mouse events with the mouse events received by wxwidgets
If someone was motivated enough to pick this up, it might make sense to try to build this in at the wxwidgets level and try to get it accepted there. It would help keep platform-specific code in the right place and also make a couple other projects happy.
-
1
-
10 minutes ago, OrbWeaver said:
Perhaps the back-end code can handle instantaneously changing the mouse pointer position more reliably than trying to lock it in place.
It doesn't matter if you want to warp the pointer every frame or only once, in both cases GTK3 chose not to support it on Wayland.
Here's the hack that Blender came up with: https://projects.blender.org/blender/blender/issues/77311
They found they had no choice but to render the cursor internally to get the intended behavior. Probably easier to do when you built your own widget toolkit like they did, rather than having to go through wxwidgets and GTK.
-
1
-
-
Yes, I probably should have been more clear. This fixes everything when running on XWayland (which emulates X the best it can but must still ultimately play by Wayland's rules).
Last time I checked, GTK3 was not planning to support mouse pointer warping at all on Wayland and left the function as a no-op in the Wayland version. It might be simplest for us to figure out an easy way to automatically force the x11 backend to be used. Wayland is increasingly becoming the default, but XWayland is not going away anytime soon.
-
1
-
-
I've figured it out! There are 2 parts:
1. The FreezePointer class has a mismatch, it blanks the cursor on the top-level window but does the pointer locking on whatever particular sub-window (i.e. the 2D view widget) calls for it. The cursor has to be explicitly blanked on the same widget that locks the pointer.
2. The clipper tool updates the cursor whenever the mouse moves, even if it's in the middle of dragging and should be hidden. It was easy enough to guard against changing the cursor while the mouse capture is active.
This also fixes the same issue that was happening in the 3D view of the model viewer (but not on the main 3D view).
I'll submit a PR shortly, @greebo or others will need to test this change on Windows to make sure it doesn't do any harm there.
EDIT: The PR is here: https://github.com/codereader/DarkRadiant/pull/37
-
1
-
-
I revisited this issue and might have had a breakthrough. I noticed that when using the clipper my cursor wasn't changing, and afterwards when the cursor was no longer hidden when the dragging problem starts happening.
If I take out the code that is supposed to change the mouse cursor when activating the clipper, the drag behavior remains correct during and after using the clipper tool.
If I remember correctly from last time I went down this rabbit hole, Wayland has restrictions on pointer locking and I think it was only allowed while the pointer is hidden. I'm guessing something with changing the cursor is failing and then it doesn't get hidden before the pointer lock happens, causing Wayland to reject the pointer lock request. And when the pointer doesn't get locked, the math to calculate the drag amount goes all wonky.
@MirceaKitsuneor others, if you'd like to try a quick and dirty workaround, find the
void OrthoView::setCursorType(CursorType type)function and put a return statement on the first line so it doesn't actually change the cursor.
I'll see if I can figure out what's actually going wrong when setting the cursors so we can make a proper fix.
-
1
-
-
I've been feeling the itch to start mapping again, and I'd like to pick up my stalled WIP for the next FM building off my first one. If we end up with lighter contest requirements I'd run with this for the fun of participating. If my FM doesn't end up meeting contest criteria I'll still keep the October timeframe as a goal though.
A mild requirement like "include a nod to a classic Thief/TDM map somewhere in your mission" sounds like a nice way to keep participation up without going full free-for-all.
-
14 hours ago, MirceaKitsune said:
I think there would be one way actually: What if DR didn't require cursor wrapping at all? Just translate mouse movement as it happens and don't care where the mouse pointer is located!
The problem comes when the mouse leaves the window. For example, if you start dragging the 3D view to turn left and your mouse gets all the way to the left side of the window, you won't be able to keep turning left. In order to turn left infinitely, the mouse pointer has to get snapped back to give you room to keep moving the cursor left.
-
I came across this bug report on wxwidgets: https://github.com/wxWidgets/wxWidgets/issues/23778
The short of it is that GTK decided not to support mouse pointer warping on wayland. There may be some sort of workarounds by making direct wayland calls, but I'm not sure yet if that's something we could even do from our layer, or if it would have to happen within wxwidgets.
-
1
-
-
I gave it a try, and mine crashed with the same segfault the first time I tried. I've attempted to reproduce it while running under GDB and haven't gotten it to crash again yet. Each time I started it it up the same way without moving.
I did a little source code snooping and the only places I found that would print out that particular message "Getting threadname failed" would be where Sys_GetThreadName is called to print out some information when a mutex is busy, deadlocked, or not locked when it should be; or also when a thread is destroyed.
If I manage to catch a backtrace I'll share it here or on the bug tracker.
-
1
-
-
It's not specific to the flatpak version, it happens in my dev build on Arch linux too.
-
Would you mind checking the other windows listed on https://bugs.thedarkmod.com/view.php?id=6165 to see if they cause crashes as well?
-
15 hours ago, nbohr1more said:
4) Models need to be split at light boundaries. If a single light touches a model the engine will do light geometry calculation for the whole model. If enough lights hit a large model it can severely impact performance. Brushes will auto-split on light boundaries but often split in less optimal locations so it has become the convention to use func_static geometry to force brushes to split in the preferred locations
Is this still true now that 2.11 is out with this feature?
I've been wondering about whether this might open up the possibility to use larger models for things other than terrain, for example modeling a building at a time in Blender and then assembling them into a street in DR. I'll probably at least test it out someday...
-
I doubt it's something on our end, as we just tell flatpak that we need OpenGL support and it's supposed to figure out the rest. I'll see if I can read up on it a little though. Flatpak has many advantages, but storage space efficiency is not one of them.
-
1
-
-
I just updated the flatpak, so it should hit flathub in a little bit.
-
3
-
Wishlist For Darkradiant
in DarkRadiant Feedback and Development
Posted
I haven't been around much lately either, and if someone officially picks up ownership of the DR release process I'd be happy to handover the flathub repo and provide guidance on how to use it if needed.