openmw issueshttps://gitlab.com/OpenMW/openmw/-/issues2019-03-18T11:20:58Zhttps://gitlab.com/OpenMW/openmw/-/issues/4695Optimize Distant Terrain memory consumption2019-03-18T11:20:58ZAndrei KortunovOptimize Distant Terrain memory consumptionBasically, Distant Terrain causes no issues with clean game, but with Tamriel Rebuilt is consumes near 2GB of memory itself, also there are freezes during turning. On machines with low amount of available memory it can cause "out of memo...Basically, Distant Terrain causes no issues with clean game, but with Tamriel Rebuilt is consumes near 2GB of memory itself, also there are freezes during turning. On machines with low amount of available memory it can cause "out of memory" errors, especially on x86.
It seems we load data for the whole game world.
Possible improvements:
1. Re-use data for "default" underwater nodes.
2. Unload data, if we do not render this cell.openmw-0.46https://gitlab.com/OpenMW/openmw/-/issues/4864Better bounding volumes for better near/far plane computation2020-09-08T21:01:34ZAnyOldName3Better bounding volumes for better near/far plane computationRight now, we only compute the near and far planes when shadows are enabled and `compute tight scene bounds` is too. This stops shadow map space being wasted on empty space below ground.
We have to compute the near and far planes based ...Right now, we only compute the near and far planes when shadows are enabled and `compute tight scene bounds` is too. This stops shadow map space being wasted on empty space below ground.
We have to compute the near and far planes based on primitives as (potentially among other things) the water plane has an undesirable bounding volume, so we can't use bounding volumes. This is accurate, but slow. A faster, but still sufficiently accurate alternative could be implemented.https://gitlab.com/OpenMW/openmw/-/issues/4866Don't bind diffuse maps when rendering shadow maps for objects without transp...2021-12-05T16:21:10ZAnyOldName3Don't bind diffuse maps when rendering shadow maps for objects without transparencyCurrently, any drawable with a diffuse map gets that diffuse map bound during shadow map rendering. We only actually need to do this for objects with transparency (as they might have a silhouette dependent on the diffuse map).
OpenScene...Currently, any drawable with a diffuse map gets that diffuse map bound during shadow map rendering. We only actually need to do this for objects with transparency (as they might have a silhouette dependent on the diffuse map).
OpenSceneGraph doesn't offer a simple way to make parts of StateSets depend on other parts of StateSets, so unless there's a way of implementing a custom mechanism (e.g. a custom render bin), this optimisation isn't possible. However, @bzzt seems to have implemented a custom render bin, so my best guess is that this is why.https://gitlab.com/OpenMW/openmw/-/issues/5195SearchVisitor constructs a new string every call2019-10-28T22:35:08ZIcecream95ixn@disroot.orgSearchVisitor constructs a new string every callEvery time [SearchVisitor](https://gitlab.com/OpenMW/openmw/blob/master/apps/openmw/mwworld/cellstore.cpp#L387) is used, it constructs a string as part of calling getRefId().
```c++
if (ptr.getCellRef().getRefId() == *mIdToFind)
```...Every time [SearchVisitor](https://gitlab.com/OpenMW/openmw/blob/master/apps/openmw/mwworld/cellstore.cpp#L387) is used, it constructs a string as part of calling getRefId().
```c++
if (ptr.getCellRef().getRefId() == *mIdToFind)
```
Because this function is called millions of times, the cost of constructing the string quickly adds up - while profiling loading in OpenMW, I found that over 10% of savegame loading is spent constructing strings in this function.
The easiest solution is adding a function to MWWorld::CellRef, maybe `const std::string* getRefIdPtr() const`, which returns a pointer, and then making the above code use that new function.
(The only other significant user of getRefId is readReferenceCollection, which has around 30 thousand calls loading a single save)Alexei KotovAlexei Kotovhttps://gitlab.com/OpenMW/openmw/-/issues/5701Convert osgAnimation::RigGeometry to double-buffered custom version2022-08-06T10:57:14ZNelsson HuotariConvert osgAnimation::RigGeometry to double-buffered custom versionOSG animation formats (e.g. dae) use `osgAnimation::RigGeometry` and `osgAnimation::MorphGeometry`, but quoting @AnyOldName3 from https://gitlab.com/OpenMW/openmw/-/merge_requests/421#note_450412434 :
> These have dynamic data variance, ...OSG animation formats (e.g. dae) use `osgAnimation::RigGeometry` and `osgAnimation::MorphGeometry`, but quoting @AnyOldName3 from https://gitlab.com/OpenMW/openmw/-/merge_requests/421#note_450412434 :
> These have dynamic data variance, which tells OSG they're not thread-safe, so to delay the next frame's cull until the current one's draw has dealt with them. That's not ideal as in the worst case, it can halve your framerate. This is discussed here: https://wiki.openmw.org/index.php?title=Rendering_Architecture#Threading_considerations.openmw-0.48Nelsson HuotariNelsson Huotarihttps://gitlab.com/OpenMW/openmw/-/issues/5893Implement move assignment operators for RefData and ESM::Variant2021-06-22T05:23:01ZAndrei KortunovImplement move assignment operators for RefData and ESM::VariantCoverity Scan suggests to implement move assignment operators for these structs:
1. ESM::Variant, which is used to store value for table cells in the editor:
```
condStruct.mValue = ESM::Variant();
```
2. RefData, which is used to sto...Coverity Scan suggests to implement move assignment operators for these structs:
1. ESM::Variant, which is used to store value for table cells in the editor:
```
condStruct.mValue = ESM::Variant();
```
2. RefData, which is used to store data in the every LiveCellRef:
```
mData = RefData (state, mData.isDeletedByContentFile());
```
Move operators will allow to increase performance a bit and fix two Coverity's complaints