Performance on Drawing Lightened Scene

[Glocke]

Ok, makes sense But to be honest, I'm unsure how I could optimize the algorithmic approach.. maybe using some additional culling to determine which edges are really hit by a light's ray...

[Hapax]

Where is that extra 0.1% of time coming from? (They keep adding up to 100.1%)

[Glocke]

Where is that extra 0.1% of time coming from? (They keep adding up to 100.1%)

I guess its up to some rounding issue.

I reran the profiling analysis for few edges and many lights:

(click to show/hide)

Flat profile:

Each sample counts as 0.01 seconds.
 no time accumulated

  %   cumulative   self              self     total          
 time   seconds   seconds    calls  Ts/call  Ts/call  name    
  0.00      0.00     0.00     7200     0.00     0.00  getFarPoint(sf::Vector2<float> const&, sf::Vector2<float> const&, sf::Rect<float> const&)
  0.00      0.00     0.00     7200     0.00     0.00  LightingSystem::prepareLight(Light const&)
  0.00      0.00     0.00     3600     0.00     0.00  LightingSystem::updateShadow(sf::View const&, Light const&, std::vector<Edge, std::allocator<Edge> > const&)
  0.00      0.00     0.00      100     0.00     0.00  Light::Light()
  0.00      0.00     0.00       36     0.00     0.00  LightingSystem::updateShadows(sf::View const&, sf::View const&, std::vector<Edge, std::allocator<Edge> > const&, std::vector<Light, std::allocator<Light> > const&)
  0.00      0.00     0.00        9     0.00     0.00  frame_dummy
  0.00      0.00     0.00        2     0.00     0.00  LightingSystem::~LightingSystem()
  0.00      0.00     0.00        1     0.00     0.00  _GLOBAL__sub_I_main
  0.00      0.00     0.00        1     0.00     0.00  LightingSystem::resize(sf::Vector2<unsigned int> const&)
 

Does this mean that there is no bottleneck in this case?

[eXpl0it3r]

Well think about it. Do you need to call prepareLight or getFarPoint 7200 times per (not sure how long that was sampled over)?

[Glocke]

Well think about it. Do you need to call prepareLight or getFarPoint 7200 times per (not sure how long that was sampled over)?

prepareLight() is called twice per light per frame (could be reduced to once maybe). But calling it once is minimum because I don't want to have one sprite per light.. it's unnecessary from my point of view.
getFarPoint() is called once each pair of lights and edges, because each light could hit each edge. As mentioned: num_lights x num_edges is just an upper bound and not necessary in each case. I think that's the best way to go for me atm.

[Laurent]

Yes, if not already done, you should use space partitionning to limit useless computations (edges not in range of lights, for example).

[Glocke]

Yes, if not already done, you should use space partitionning to limit useless computations (edges not in range of lights, for example).

Thx, but this is already done Except not culling edges that are hidden by other edges but still visible in the scene.

But anyway: My problem also occures if I have lots of lights and few edges .. extreme case: 50 lights and 1 edge (assuming space partitioning is already applied). Then getFarPoint() will be called 50x (like 1 Light and 50 Edges which runs perfectly fine). The profiler tells me nothing (see spoiler above).