Project

General

Profile

Bug #2698

Snow and rain VFX move with the player

Added by Thomas Staudinger over 2 years ago. Updated about 1 month ago.

Status:
Closed
Priority:
Normal
Category:
Rendering
Target version:
Start date:
06/17/2015
% Done:

100%

Reproducibility:
Always
Operating system:
Other
Severity:
Normal

Description

In OpenMW the snow effect moves with the players view, which gives it a cheap overlay look, see video for comparison with vanilla Morrowind:

https://www.youtube.com/watch?v=Yt37MAQ0CfQ

Steps to reproduce:
1. changeweather [YourRegion] 8
2. Observe

OpenMW version: 0.36.1

Note: The snow in OpenMW also sometimes has kind of a patchy look, which can be seen in the video too


Related issues

Related to OpenMW - Bug #3404: replacing raindrop.nif doesnt change the nif ingame Confirmed 05/26/2016
Duplicated by OpenMW - Bug #3536: Incorrect rain vfx Rejected 09/09/2016

Associated revisions

Revision 97ec38af
Added by scrawl . about 1 month ago

Merge pull request #1492 from drummyfish/master

fix rain/snow moving with player (issue #2698)

History

#1 Updated by scrawl . about 2 years ago

  • Category set to Rendering

Looks like MW isn't using snow.nif at all. The snow is a manual simulation like the rain is.

#2 Updated by Lars Söderberg about 2 years ago

Jannik Heller wrote:

Looks like MW isn't using snow.nif at all. The snow is a manual simulation like the rain is.

Not sure how relevant this is, but I remember having a mod that changed how the snow looked. It changed it from dots to flakes . A quick search says BM_Snow01.nif might be it.

#3 Updated by Alexei Dobrohotov 10 months ago

  • Target version set to openmw-0.42

#4 Updated by Marc Zinnschlag 8 months ago

  • Target version changed from openmw-0.42 to openmw-0.43

#5 Updated by Miloslav Číž 5 months ago

This issue also applies to rain (I tested it by slowing down the rain by changing mRainSpeed). It's caused by appending the rain node to the sky root node in SkyManager::createRain(), so the rain moves with the sky, which moves with the player. Any idea about a simple approach to fixing this?

#6 Updated by Alexei Dobrohotov 5 months ago

  • Subject changed from Snow effect moves with player to Snow and rain VFX move with the player

#7 Updated by Alexei Dobrohotov 5 months ago

  • Duplicated by Bug #3536: Incorrect rain vfx added

#8 Updated by Alexei Dobrohotov 5 months ago

  • Related to Bug #3404: replacing raindrop.nif doesnt change the nif ingame added

#9 Updated by Andrei Kortunov 4 months ago

  • Status changed from New to Confirmed
  • Operating system changed from Windows to Other

#10 Updated by JP Mack 4 months ago

Could this be resolved using the OSG Precipitation module?

#11 Updated by Alexei Dobrohotov 2 months ago

  • Target version changed from openmw-0.43 to openmw-1.0

#12 Updated by Miloslav Číž about 2 months ago

So basically the issue is not that the emitter moves with the player, but that the particles it emits move with the player. The solution would be to tell the particles to parent themselves to the scene, not the sky, when they're spawned. Does anyone know how this would be done with OSG?

#13 Updated by Miloslav Číž about 2 months ago

OK, I tried

emitter->setReferenceFrame(osgParticle::ParticleProcessor::ABSOLUTE_RF)

in SkyManager::createRain(), but that doesn't seem to work.

#14 Updated by Miloslav Číž about 2 months ago

Update: I reparented the rain emitter from sky node to the root scene node and made a custom Placer class inherited from BoxPlacer that places each new particle relatively to the camera position. This solves the issue, the rain drops now move independently of the camera, but the fact that the emitter is not parented to sky causes other problems. If I figure out how to make the emitter NOT inherit its parent's position, I can reparent it back to sky and the issue will be solved.

#15 Updated by Alexei Dobrohotov about 2 months ago

  • Status changed from Confirmed to In Progress
  • Assignee set to Miloslav Číž
  • Target version changed from openmw-1.0 to openmw-0.43

#16 Updated by Alexei Dobrohotov about 1 month ago

  • Status changed from In Progress to Resolved
  • % Done changed from 0 to 100

#17 Updated by Alexei Dobrohotov about 1 month ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF