Jump to content
The Dark Mod Forums


  • Posts

  • Joined

  • Days Won


Everything posted by greebo

  1. 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.
  2. 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.
  3. New 3.0.0pre2 build is available in the first post.
  4. 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.
  5. 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.
  6. Depends on whether it's useful or not It's just the first thing I got working when migrating the renderable objects.
  7. 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.
  8. @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.
  9. 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?
  10. 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.
  11. Hm, seems to be more involved then. Thanks for investigating that.
  12. 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.
  13. Here's the pre-release build 3.0.0pre8, we're getting closer to the finish line. It's about time for a new major release - not just because of the changes of this build, but for all the improvements made over the last few releases. I'm going to need your help stabilising this release, with all the renderer changes things are bound to require a few tweaks. Most time since 2.14 has been spent on the renderer, which should now be faster in regular (non-lit) render mode. Lit render mode is probably not going to be faster, but at least more accurate. You can activate Shadow Mapping, and the interaction shader code has been ported over from TDM to produce the same look as the game. Starting with this release, the user settings will be saved separately for each DR version, meaning that this release won't mess with the settings of the previous versions, including keyboard shortcuts, colours, last used maps, etc. DR will try to import and use any settings of previous releases, but it won't change them. For more things that have changed or fixed, see the list below. Download Windows Portable x64: https://drive.google.com/file/d/121ibqqYMKqRqjcQ1zS0HtM4JO0ADrgRo/view?usp=sharing Download Windows Installer x64: https://drive.google.com/file/d/1209hG92chVzqOc-iaFDzJ0cBfQucDad8/view?usp=sharing Linux folks need to compile this stuff from source, instructions for various distributions are on the wiki. If you happen to run into a crash, please record a crashdump: How to record a crashdump Changes since 2.14.0 can be seen on the Bugtracker changelog, here's the summary: #5787: Feature: Add "Create Particle" to right-click orthoview drop-down menu #219: Feature: Shadow mapping support #5761: Feature: Cut functionality to complement copy and paste #5757: Feature: Ability to center 3D camera on selected entity #5927: Feature: Save user settings by application version #5848: Feature: MD5 Animation Viewer: show current frame & total frames #5849: Feature: MD5 Animation Viewer: jump to frame #5905: Improvement: Safeguard warning against Loss of Layering #5872: Improvement: Option to filter skins out of search results in the Choose Model dialogue #5909: Improvement: Revisit Interaction Shader to get closer to the TDM looks #5822: Improvement: UI tweaks for worldspawn-to-entity conversion #5873: Improvement: Entity inspector should recognise spawnargs beginning with "sprS_" as def spawnargs #5825: Improvement: Allow absolute paths for snapshots #5910: Improvement: Entity Inspector: classname field should always be read-only, to force use of the "Choose entity class" button #5925: Fixed: Objective GUI doesn't display properly in some places #5919: Fixed: Crash on loading certain maps #5829: Fixed: Entity inspector shows inherited spawnargs of previous selection #5853: Fixed: DR overwrite order for defs is different from TDM's #5897: Fixed: X/Y and Camera View bindings don't save properly #5858: Fixed: "Replace Selection with exported Model" sets classname to "func_static". #5864: Fixed: Map -> Edit Package Info (darkmod.txt)... crashes DarkRadiant #5846: Fixed: Rotating a func_static result to random stretch textures #5840: Fixed: DR crashes when syncing with remote Git repository #5847: Fixed: Switching visibility of Github repo from public to private causes crash #5841: Fixed: Dockable window layout doesn't save new floating XY views #5844: Fixed: "Choose skin..." button on custom model spawnargs shows skins for main model spawnarg #5826: Fixed: Entity inspector considers inherited colors black #5885: Fixed: ReloadDefs moves def_attached light crystals to entity origin #5901: Fixed: .lin files can't be opened if different case than .map name #5884: Fixed: Model chooser radio box selection issue #5836: Fixed: Changing multiple lights between omni/projected resets colours to black Changes since 3.0.0pre1 #5934: Selection overlay is z-fighting on patches #5932: ForceShadows materials are not casting shadows #5933: Moving brushes doesn't update the scene in lit render mode Changes since 3.0.0pre2 #5941: Selected Skin not showing in ModelSelector #5935: Defs takes longer every time #5939: Texture tool Free rotation not showing anymore #5940: Light diamond frequently disappears on colour change until it's moved again #5938: Additive blend stages over black diffusemap are z-fighting #5936: Ambient lights don't render properly in lighting preview mode Changes since 3.0.0pre3 #5949: Fixed: DR crash with combination of mouse buttons pressed #5948: Fixed: Manipulation Vertex Dots are hard to see #5947: Fixed: Git Sync Exception: too many redirects or authentication replays #5907: Feature: Allow way to hide some entities in Create Entity list #5946: Improvement: Speaker radii should be transparent #5945: Improvement: Light diamonds should be transparent again #5937: Fixed: Sound radius spheres don't always update #5943: Fixed: Brush manipulation is laggy in huge maps #5942: Fixed: Missing brushes when opening alphalabs1 from vanilla Doom 3 PK4s Changes since 3.0.0pre4 Reduced Frame Buffer Count from 3 to 1, this should reduce RAM consumption a lot #5953: Wireframe object drawing order is changing between sessions #5951: "Hide Deselected" is slowed when there's a lot of patches present in the scene #5950: Visibility checks are slowing down front-end render pass Changes since 3.0.0pre5 #5955 + #5956: Fixed: Player start entity is invisible in 3.0.0pre5 #5959: Geometry Corruption / weird diagonal lines messing up the view Changes since 3.0.0pre6 #5966: Light entity radious colour changes as you pan the camera around. #5964: Cannot manipulate func_emitter after creation #5965: Resizing light entites via light_radius in property inspector broken #5963: More Geometry Corruption in Camera View (Lighting Mode) #5960: Crash in MD5 model viewer Changes since 3.0.0pre7 #5968: origin of player start entity misaligned #5969: Cannot snap selected patch vertices to grid Thanks for testing, as always!
  14. I assume Shift-MMB (PasteTextureProjected) might give you better results, if a brush happens to be nearby. It will do the same projection as Cap texture, but using the given plane of the brush face. The Cap Cycle Texture command is using the fixed X, Y and Z planes for the projection, without the need to read it from a brush face.
  15. Oh, I can see that now. It has been removed in version 2.1.0, sometime in 2016. It has been removed since "Natural" is doing a similar job, or pasting projected from adjacent brushes. What's the exact use case of Cycle Cap that cannot be achieved with the other functions?
  16. Which function are you referring to? And in which version has it been removed from DarkRadiant?
  17. I didn't mean to suggest to move or migrate dmapping code into DR (I already failed once doing so), and you're correct that keeping DR up to date with any dmap changes would be most cumbersome. That's why I just meant to load a dmap.dll module and pump data into it, which would make it spit out some portalling or proc information. Pretty much like the game is using the Maya SDK. It just needs to load the DLL and feed the right data format into it to be able to use it.
  18. Not only the version control system, also the data structures and coding paradigms are like from two different planets. I could merely use the engine code as rough blueprint, and it was immensely helpful for me, I could learn a lot about more modern openGL. Speaking about sharing code, what would be really nice would be to have a plugin containing the DMAP algorithm. But from what I remember when trying to port this over to DarkRadiant years ago, that code is also tied to the decl system and the materials and even image loading. Maybe @stgatilov, having worked on dmap recently, might share some insight on whether this piece of code would be feasible to isolate and move to a DLL with a nice interface. Having leak detection and portalisation code available to DarkRadiant would be beneficial for renderer performance too. Right now, it's completely unportalised and slow as heck.
  19. I managed to port some of the shadow mapping code over to DR, it can now support up to 6 shadow-casting lights. Of course, it'll never be as pretty as TDM, and nowhere near as fast, but it's a start.
  20. The GUI text placement code is definitely not perfect, I've been reverse-engineering it back in 2010. If you have a concrete example, I can look into it and compare to it to the TDM sources, which we have available in the meantime.
  21. It's the way they are internally stored to reduce draw calls, but they are indeed similar. I implemented the IWindingRenderer first, since that was the most painful spot, and I tailored it exactly for that purpose. The CompactWindingVertexBuffer template is specialised to the needs of fixed-size Windings, and the buffer is designed to support fast insertions, updates and (deferred) deletions. I guess it's not very useful for the other Geometry types, but I admit that I didn't even try to merge the two use cases. I tackled one field after the other, it's possible that the CompactWindingVertexBuffer can now be replaced to use some of the pieces I implemented for the lit render mode - there is another ContinuousBuffer<> template that might be suitable by the IWindingRenderer, for example. It's very well possible that the optimisation I made for brush windings was premature and that parts of it can be handled by the less specialised structures without sacrificing much performance. The model object is not involved in any rendering anymore, it just creates and registers the IRenderableSurface object. The SurfaceRenderer is then copying the model vertices in the large GeometryStore - memory duplication again (the model node needs to keep the data around for model scaling). The size of the memory doesn't seem to be a problem, the data is static and is not updated very often (except when scaling, but the number of vertices and indices stays the same). The thing that makes surfaces special is their orientation, they have to be rendered one after the other, separated by glMultMatrix() calls. Speaking about writing the memory allocator: I was quite reluctant to write all that memory management code, but I saw no escape routes for me. It must have been the billionth time this has been done on this planet. Definitely not claiming that I did a good job on any of those, but at least it doesn't appear in the profiler traces.
  22. Yes, this is interesting. It's achievable, with some cost, of course. Right now, the Shaders themselves implement the interfaces IWindingRenderer, IGeometryRenderer and ISurfaceRenderer. A different authority could implement these interfaces, but it needs to map the objects to the Shaders somehow (likely by using a few std::maps). The renderer then calls that authority to deliver that information, this way we can separate that information. The fullbright backend renderer needs that info when processing the sorted shader passes. Currently they ask their owning shader to draw its surfaces, this has to be moved elsewhere. The lighting mode renderer is using the objects as delivered by the render entities, this is not involving the Shader doing the housekeeping. So this renderer is already heading more towards this direction.
  • Create New...