UFO: Alien Invasion Issue Tracker
UFO: Alien Invasion
Go to the previous open issue
Go to the previous issue (open or closed)
star_faded.png
Please log in to bookmark issues
icon_project.png UFO: Alien Invasion / Closed Bug report #2847 Particle light effects are not faded
Go to the next issue (open or closed)
Go to the next open issue
This issue has been closed with status "Closed" and resolution "Not determined".
Issue basics
  • Type of issue
    Bug report
  • Category
    Battlescape
  • Targetted for
    Not determined
  • Status
    Closed
  • Priority
    3. Normal
User pain
  • Type of bug
    Not triaged
  • Likelihood
    Not triaged
  • Effect
    Not triaged
Affected by this issue (1)
People involved
Times and dates
  • Posted at
  • Last updated
  • Estimated time
    Not estimated
Issue details
  • Resolution
    Not determined
  • Reproducability
    Not determined
  • Severity
    Not determined
  • Complexity
    Not determined
  • Platform
    Not determined
  • Architecture
    Not determined
Attachments (0)
There is nothing attached to this issue
Duplicate issues (0)
This issue does not have any duplicates
Description
[http://sourceforge.net/p/ufoai/bugs/2847 Item 2847] imported from sourceforge.net tracker on 2013-01-28 19:50:51

I think the shaders are a little bit broken for the dynamic lights from particles. The light effect is rendered as circle but does not fade out on the edges. (e.g. use the plasma weapon to see the effect)
===== Comments Ported from Sourceforge =====

====== tlh2000 (2011-05-08 08:23:25) ======

lightcolor, lightsustain and lightintensity are the particle parameters (see base/ufos/ptl_weaponsfx.ufo)

R_AddSustainedLight and R_AddLight are the functions to add those lights to the world and R_EnableLights will activate the lights on a per-frame-basis.


====== tlh2000 (2011-05-08 08:27:13) ======


====== tlh2000 (2011-05-08 08:27:25) ======


====== alextishin (2011-05-11 15:31:43) ======

Which version was it? Cannot reproduce with a current master.
And considering the code in current master, dynamic lighting is disabled for everything but the mesh models (see the R_EnableDynamicLights, especially shader parameter DYNAMICLIGHTS which enables them)
====== tlh2000 (2011-05-11 20:24:39) ======

Latest Master. Maybe i described the Bug wrong. Did you had a Look at the AttachedScreenshots?
====== alextishin (2011-05-13 16:00:58) ======

Did look at screenshots, but, to be honest, 256 colors pics are leave a lot for imagination :(
From what I see, there are light spots on brush geometry, which should be impossible with current code. Please provide better quality images! Cropped 24-bit .png with JUST the (wrong) light spot will be enough. console.log will be good, too, so I will know the exact hardware&settings.

On the other hand, running skirmish at night (I try to schedule my Firebird to land at day in campaign game, so there are few night missions for me) shows that models do keep that blue illumination after firing plasma weapons. Will investigate the cause.
====== tlh2000 (2011-05-13 16:13:02) ======


====== tlh2000 (2011-05-13 16:13:13) ======


====== tlh2000 (2011-05-13 16:13:25) ======


====== tlh2000 (2011-05-13 16:13:34) ======


====== tlh2000 (2011-05-13 16:13:46) ======


====== tlh2000 (2011-05-13 16:14:44) ======

i've attached some new screenshots - ufo03-ufo07

btw: light spots on brush geometry is implemented in the shaders.
====== alextishin (2011-05-14 20:28:43) ======

Did some more investigating on the issue. Yes, you're right, fragment shader does calculate lights for the brush geometry. Somehow missed that :(

On the other hand, on my system there are no lights on the brush geometry. Using th debug shader, I found that all light passed to fragment shader have constantAttenuation parameter set to zero, and since that parameter is used as the light radius, such value kills the light. Considering that UFO:AI sets the right value for this parameter, that could be the other part of the same issue (always clearing radius to zero in my case, and never doing that in yours).
====== alextishin (2012-03-07 01:00:35) ======

Ok, that issue seems to be fixed for a long time, so I'm setting it to pending state.
====== aduke1 (2012-09-17 21:57:43.290000) ======

- **status**: pending --> closed
- **milestone**: --> 2.0-RC2
Steps to reproduce this issue
Nothing entered.
Todos (0 / 0)
Issue created
footer_logo.png The Bug Genie 4.3.1 | Support | Feedback spinning_16.gif