OrbWeaver

Actually I might be confusing two different things. What the latest LWO exporter fixes is the smoothing angle. Previously this was hard-coded at some weird value slightly less than 90°, but this can now be configured to smooth everything, smooth nothing, or use the Autosmooth Angle setting on the object. I have no idea if explicit smooth groups are supported, or if this is even a thing in Blender.

As far as I know the most up-to-date one is the script I maintain (there is a single tdm_export script which supports both ASE and LWO export). However I haven't specifically tested with the latest Blender 3.4 series, so it's possible that it will need an update. I believe this information is out of date. The problem of LWO losing smoothing information was caused by the Blender exporter itself ignoring object-specific data and enforcing a hard-coded smoothing angle. This is now fixed in my latest version, although the old behaviour is selectable at the time of export if you don't want to deal with object smooth groups. As far as I can recall, when I was testing this, the smoothing options did take effect in the engine (although I couldn't say whether they were 100% mathematically correct).

Would you be able to attach or upload the map (or any other map which shows the same issue, if you don't want to share a WIP)? Even if the map has become corrupted, we ought to be able to handle this more gracefully and perhaps recover whatever data we can read even if some is missing. Under no circumstances should we hard crash regardless of what sort of corruption is in the map file.

This was the relevant SVN change: r9525 | orbweaver | 2021-07-30 21:17:43 +0100 (Fri, 30 Jul 2021) | 11 lines Use correct format for uploading precompressed ATI2 normal maps When the 'ATI2' FOURCC is seen in a precompressed DDS file, use the GL_COMPRESSED_RG_RGTC2 internal format (matching the behaviour of image_useNormalCompression on uncompressed source images). The legacy code was using GL_COMPRESSED_LUMINANCE_ALPHA_LATC2_EXT. This is enough to get plausible looking normal maps with DDS files exported in 3Dc/BC5 format using the GIMP DDS plugin. Not tested with files exported from any other tools; it is conceivable that other FOURCCs might need handling too. Note in particular the comment about this only being tested with the GIMP DDS plugin, and that formats used by other tools might need additional changes.

You used bash for this? Why not a proper cross-platform language with decent text processing support that others might be able to understand and maintain, like Python?

This exact behaviour can be created using a blendLight using the blend filter blend mode. The light becomes a volume which simply multiplies (darkens) its projected texture with the texture of contained objects, almost like a 3D volumetric decal.

I have a 1440p screen and I also find certain lines a bit thin, but currently there is no way to control it.

Fixed in Git revision a1f0c789f34b4bb11a132aaeb03a380da18fe6b5. I tested switching light textures in the Light Inspector and switching brush textures on the Media tab, and everything still looks fine so hopefully nothing is broken as a result of switching MaterialSelector to use a sigc::signal instead of an explicit selectionChanged callback.

The actual crash occurs on this line of LightInspector.cpp: 85 void LightInspector::shaderSelectionChanged() 86 { 87 // Get the selected shader -> 88 auto ishader = _texSelector->getSelectedShader(); The _texSelector member is still NULL here, so this is a segfault. The initialisation of _texSelector happens in setupTextureWidgets(), which is called unconditionally in the LightInspector constructor, so a missing method call is not the issue. However, the value of _texSelector is a newly-constructed MaterialSelector object, and this object takes a function pointer to the shaderSelectionChanged() in its constructor: _texSelector = new MaterialSelector(parent, std::bind(&LightInspector::shaderSelectionChanged, this), MaterialSelector::TextureFilter::Lights); It appears that this is creating a race condition: the constructor of MaterialSelector is able to call the shaderSelectionChanged callback (presumably as a result of selection changes during its Populate() method), but it isn't actually safe to call shaderSelectionChanged() until after the MaterialSelector is fully constructed and assigned to the _texSelector member. I think my preferred solution would be to remove the "selectionChanged" function parameter to the MaterialSelector constructor entirely, and replace it with a public signal_selectionChanged() which client code could connect to. This would have two advantages: No possibility of race condition, since you would have to construct the MaterialSelector before connecting to the signal. Signals are more powerful than manual std::function callbacks (e.g. they can auto-disconnect if the target object is destroyed) and are widely used throughout the codebase. However, if anything currently relies on receiving selectionChanged callbacks during the MaterialSelector construction, this would no longer work. @greebo what do you think?

I can reproduce it on Linux in a local source build. Logged as issue 6216.

I would like this option as well. I can't be bothered to hold down Ctrl and a movement key (especially when you're moving slower, so you have to hold it for ages), so I just use toggle crouch as my "creep" replacement. But being able to toggle creep would be a better option, not least because it doesn't change the camera perspective as crouch does.

I've often felt that door opening sounds were much too loud, so this sounds like a potential improvement. One problem is that certain cupboards with two doors actually play the sound twice at the same time (once for each door), making it double the expected volume. But even regular single doors often sound too loud to me.

Looks like I jumped the gun slightly. It doesn't seem to have been completely removed, but has been deprecated for several versions. Knowing Apple, I will be very surprised if they don't eventually remove it altogether in a few versions time.

I don't think you can use OpenGL at all on M1 macs (natively). Anyone who wants to make that port is going to need to write a complete Metal replacement for the renderer.