greebo

Thanks, I'll check it out in the next few days!

Same here with the Windows.h headers - they are infamous for their #defines polluting the namespaces. They are leaking through wxWidgets too. It's possible to turn those off by #define NOMINMAX and such, but it's obviously not happening, so we have min, max, near and far.

If it's not a huge problem for you, I'm happy to update the dependencies. I need to fix something else in there anyway, so a new windeps package for 2.12.0 is due anyway. Ubuntu package seems to be present: https://packages.ubuntu.com/groovy/libeigen3-dev

...and merged. Be sure to sync back at some point, since I had to rename math::near to math::isNear due to some stupid preprocessor #define of "near".

I felt the urge to check the network activity when it kept me waiting, to make sure it didn't just stall - I got around 500k/sec cloning from gitlab. I probably just ran into a bad mirror. A shallow clone of the submodule is probably a good move, since we're not really interested in the history anyway, count +1 for that. But it's not just the git pack, it's also the checkout which is fairly large, it's 1600 files (14 MB). As you put it, it's not exactly on the lightweight side for algebra I guess we're not really using all of that tree, are we?

Ok, got everything merged, and as a bonus, it's even compiling now. That submodule is *huge*, it took me 2 minutes to get it fetched and checked out. Not sure I really like that huge tree lying around, it reminds me a bit of the boost times. But I can live with it. For VC++ I added a pre-build script to check for the eigen sources, and if they're not present in the expected path, it will try to init the submodule itself by calling git submodule update -i. The wiki articles and the README.md file have been adjusted too for clarification.

@OrbWeaver it just occurred to me that I forgot to merge the most recent commits to your master branch. I'll do that for the next pre-release.

Here's the DR 2.12.0pre3 build for every interested mapper to test. For more things that have changed or fixed, see the list below. Download Windows Portable x64: https://drive.google.com/file/d/1QVbtqQzRYGOKmnvi27Fcx5IfEZXcKLGe/view?usp=sharing Download Windows Installer x64: https://drive.google.com/file/d/1MYIE1MwLpE5MOnHA1aqFj4YTegeLNyhG/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.11.0 can be seen on the Bugtracker changelog, here's the summary: #5566: Material stages with alpha test are incorrectly rendered as translucent #5572: Material Editor #5576: ASE importer needs to handle shared vertices with different normals #5552: Better support for stage transform keywords in idTech4 materials #108: Ambients don't light sides facing away #5571: Table lookup evaluation is not producing the same results as in the engine #426: Added script as "same origin clone manager tool" #2132: 3D grid feature #5546: Attached light radii are the wrong colour if "Override light volume colour" is active #289: ESC to close dialogs with Cancel #5556: Add missing image dimension reads to Quake 3 legacy brush parser #1709: Show light_radius on 'other' entities #5541: Customisable GUI layout ("Dockable") #5534: Opening the Create Entity dialog a second time will present an empty tree view #994: Show attached (light) entities #5530: "Toggle 16x16 grid" function in the Particle Editor broken #5527: UI Manager cleanup #5524: Add portal_sky filter to default filters #4644: Use of BITMAP field in ASE differs from TDM #5518: Newly added or imported items don't use the location of previously selected item #5460: Newly drawn brushes don't use height of previous selection with "Show Size Info" switched off #4846: Rotation widget does not re-center on selected object #5267: Duplicating model and moving with Alt-arrow results in pivot on original model when trying to rotate afterwards #5465: Brushes with no visible surface towards orthoview "camera" are invisible in orthoview #4735: Can't select one-sided models in certain 2D views #5266: Twosided models can only be selected from one side #4791: Copy model/entity/prefab paths to clipboard Changes since 2.12.0pre2: Switched Matrix algorithms to Eigen library #5589: Material Editor: Add Reload Images button to reload the textures of the selected shader #5590: ASE import failure loading models/darkmod/nature/flowers/flowers_patch_01.ase #5586: Crash at shutdown when Dockable layout is active #5585: Extend MaterialManager scripting interfaces by editing methods #5572: Add context menu option "Open in Material Editor" to MediaBrowser tree Thanks for testing, as always!

Btw, I'm running into the same problem after updating to 2.09. Tried changing all of the aforementioned CVARs, but nothing solved it. I ended up updating to one of the test builds (I think test15973-8787). I'm on a laptop with an Intel UHD 620 and a dedicated nVidia GeForce MX150 here. Switching GPUs doesn't change anything, except that the screen is turning all white on Intel, instead of all black on nVidia. I haven't tried wiping the entire TDM tree to see if any old assets (like glprogs) might be lying around, conflicting with the downloaded ones. I also haven't tried yet recompiling TheDarkModx64.exe, to have the glprogs copied over afresh in the post-build step. edit: a fresh download of 2.09 is working, so it seems something in my existing darkmod/ tree is messing things up.

That was my main concern. The whole reason the windeps are kept separate is that Linux users don't need to check out all these windows binaries. If there is no easy distinction and Linux users have to unconditionally checkout all submodules, then the point is moot.

Ok, I'll also update the wiki compilation articles then, because including the submodules while cloning is something I tend to forget myself. It left me scratching my head two times when trying to build something from source in the past, until I realized I might be missing something the sources expect to be there from the start. Re libfmt: in this case I was forced to include it in the source tree, because I couldn't get it to compile with the Ubuntu libfmt package. It can be configured as header-only (by #DEFINE) or as static library, but the debian package somehow had conflicting linker flags, and I couldn't get it to link (I think it was due to the -fPIC setting). On a related note, I obviously haven't googled yet, but would it be possible to configure the windeps as optional submodule and have Windows coders check it out on purpose? I have all the binaries in a separate repository, so this would make the compilation instructions a bit easier.

Nice, and interesting too. Thanks for the heads up, I'll be happy to do the necessary steps in studio once I'm updating the master again. Plus thanks for carving out all the unit tests, the test suite is really starting to grow! With regards to the external submodule, is there a strong reason to include it through git? So far all the third-party libs have been specified as (cmake) package dependency (like libpng, libvorbis, etc.), and the Windows side has been handled by extracting the windeps zip to the working tree. Has Eigen different requirements? Or should we move more stuff to submodules?

I got a pre-release build to share, in case somebody wants to tinker with the current state a bit. I probably won't be able to work on it for a few days, so I might as well get some feedback in the meantime. Don't use this for your productive mapping work, it's probably full of glitches and crashes. The Material Editor can be found in the "Entity" menu for the moment being. DarkRadiant 2.12.0pre1 portable x64: https://drive.google.com/file/d/14Q9d1N7iuv1g8EquSb7IlF5zhCpYn6j9/view?usp=sharing

Thanks, should be fixed now.

I think that's already possible, yes. Since all the model data is in the CShader / ShaderTemplate pair, not everything needs to be exposed in a corresponding control. I'm not religiously adding keywords just for the sake of having them, if we have some consensus about certain options to be left out completely I'm happy to throw them out. The corresponding keywords in existing materials would not be changeable by the UI, but very likely be preserved in the ShaderTemplate that will be written to the .mtr file. Setting those missing keywords will have to be done in a text editor (maybe even in that text definition box?). Some settings are connected to or interfering with or can be combined with each other, like all the mask keywords, vertex colouring (colored vs. color vs. red, green, blue, alpha) and the various MACROs. So when exposing any of those, the related properties need to be there as well. One more thought: while there are some keywords that are not widely unused (like isLightGemSurf which should only be used on the lightgem) and even dead horses (like renderbump/flat - I think nobody's using that anymore), the rest of them can actually be fun to experiment with and put to good use. Perhaps the editor could help them getting more surface coverage? With regards to a possible basic vs. advanced editing mode, are there any suggestion lists from you guys what the basic editing mode should contain? I consider diffuse/bump/specular to be self-explanatory next to material type, description, noshadows, alphaTest, twosided, decal stuff. What else? Is blend mode selection already "advanced"?

Yes, using tabs to switch between simple modes is one way and might even be the easiest way. Another way would be a toggle (Advanced Options - we don't have the Windows on/off slider controls in wxWidgets, but something like this). The tricky thing will be how the simple mode is going to deal with materials that use more than the basic options - are they just hidden and will they get dropped when a stage is edited in simple mode? Or can it detect such materials and simple mode will be disabled for those materials? A general consideration: One of my requirements was that any material can be opened and altered without losing anything, except for maybe formatting or redundancy - not sure if this is something worthwile pursuing? I have to read up on the latest development on frob stages. Haven't there been discussions of getting rid of that frob stage and have it handled by the engine automatically? If a frob stage is necessary, then a button to create it would of course be very useful, agreed. Yeah, I planned to more or less copy/paste the explanations from iddevnet or modwiki to the tooltips. It's straight forward to do it in wxFormBuilder, but there was no time for that yet.

Yes, this is a good idea, it's on my list. The plan was to offer a small number of shapes (cube, sphere and a plane to test tiling behaviour) in front of a textured room. Please back up that accusation and point out all the initial ideas I ignored in this thread. If it makes you feel better, you can continue calling me incompetent or backwards, it's ok for me. And since you're not "over and out", care to explain why you edited all your posts in this thread and replaced them with dots? (It doesn't come without some irony, since your friend Biker did the same once when he got mad.)

Why, thank you!

Man, I really ought to spend more time on the forums, people around here are really helpful and full of good advice. Speaking of which, I was just about to re-read your post about getting in touch with a closed group of mappers for feedback, but it seems you edited your answer and replaced everything with a dot?

You mean it's not so suitable after all? I thought it was beautiful, with all these tabs and checkboxes. I've always been in love with those functional panels, so you can feel like you're in a control room of a nuclear power plant. (edit: I guess it wasn't that obvious, but the above was meant to be sarcastic. I'm not a huge fan of nuclear power plants in real life.)

Hm, where am I supposed to find such a group of mappers? This kind of feature development is all rather new to me, I must admit.

Thank you for this explanation. I've never heard of that iterative thing before, but it really sounds like it's a good approach. Now I'm not so sure about communication with end users. How on earth should I do that?

You mean, I should open a forum thread to get some thoughts before I even started? And post screenshots as soon as I have something? It's the fricking internet after all, where nobody has to deal with anybody else in person, and you might happen to be a fun and relaxed guy in real life, but getting this tone in return when asking for feedback is not exactly what makes this funny for me. I'm always open to listen to mappers, especially mappers, but l need constructive feedback to work with. I'm totally aware that this is not exactly a simple GUI to set up a material in 5 seconds. I have thought about having two "modes", where the simpler one hides most of the controls, where one just sets up the diff/bmp/spec triplet. It's just not there yet, and it was indeed not even the goal for this first iteration, but I can hear you guys that it looks like an airplane cockpit right now. Or maybe that simpler GUI ends up as a separate "assistant"-style dialog on top of this one? Or maybe a separate "Material Creator" GUI that is using the same preview but just features a few controls (no selecting of existing materials, just creating new ones)? Ideas? I've been working on the harder part of that quote, which was #2. Like the particle editor, it should be able to open existing materials, such that users can inspect and play around with them, talk about full syntax support. So I needed to make sure it is able to display every TDM material you throw at it, and looking at the now-defunct iddevnet.net materials page there are heap loads of options - that's why there are so many controls. It should be able to open any existing material, change anything in there and hit the save button without it destroying the original material syntax, which is not going to be easy. My ToDo-List is looking like this: Make DR materials reponsive to changes, so the preview reacts to it Get DR to export materials that have been edited Get the DR renderer up to speed, it doesn't support most of the less widely used keywords Improve the lighting preview scene with configurable light parameters Create that "simple" mode Each of these steps will take weeks, so we're still at the beginning of that story. But still, if the majority of mappers here thinks that this GUI will be a perfect waste of time, because 1) too complicated and 2) nobody wants that anyway, then please tell me right now. I'll focus on a mini-GUI with diffuse/bump/specular and forget about the rest. I'm pushing the commits to github on an almost daily basis. I know that some mappers used to build DR from source for personal use. Anyway I was thinking it would be nice having an automated nightly build which is just building and publishing whatever the code currently is looking like. I don't have such a setup though, I need to spend some time playing around with Github CI, never touched it so far. Creating a new build every day manually is too much work for me for little benefit, to be honest.

Got the first WIP shot to share. Right now the GUI can display and handle all the material and stage keywords, had to extend the parser here and there. The material is read-only (so it's currently more like a material viewer than an editor). The cube in the preview is slowly rotating and has a fixed light source in the scene. You can switch between the lighting modes, as with all the previews. There's lots of stuff left to be done, next step will be to do some ground work on the Material interfaces to make it changeable (it hasn't been designed to be altered after parsing). Once that's done, I will try to get the control bindings working, to see the updates immediately.

It's possible to disable that automatic clone offset (I think it's in the top toolbar). Not sure how many people use that option, but it's there.