LightType.Point is very slow to init

[DruggedBunny]

I've heavily re-worked Bust! (now Super Thrusting Game!) into separate classes, and been tweaking lots tonight (not that much will show), and I noticed Point lights are now working. (It may be that when I tried them before, I hadn't realised they wouldn't shine outside my orb without some alpha applied to it.)

However, Point lights seem to be extremely slow to initialise, whereas Spot lights are instant.

Source

This is located in orb.monkey2, line 34 -- try starting the game, flying away from the platform and hitting 'O'... huge pause!

        glow = New Light (model)

            glow.Type               = LightType.Point ' Very slow to init!
            glow.CastsShadow        = True
            glow.Color              = Color.HotPink * 8.0
            glow.Range              = 10.0

Change to LightType.Spot and it's instant.

I'm imagining there's some sort of gathering of scene vertex data or something (toggling it doesn't cause the delay), but couldn't immediately locate anything. (Guessing the hard work is done in the shader?)

I tried init'ing a Point light during game start, but that didn't avoid the pause on first Orb-spawn, so must be Light instance-specific, I guess.

Is this just something we'll have to live with -- initialise prior to game processing -- or should it be possible to start these lights in real time?

[blitz-research]

Setting light type just sets a field to an enum, should be pretty fast!

Will have a play with it right now.

[blitz-research]

Ok, works pretty well, how do you know it's the point light causing the init time? There is no particular reason point lights should be. Is there any way I can easily test with, say, spot lights instead?

Also, the camera gets very close to the rocket sometimes! Perhaps make camera follow a point 'behind' or in some way relative to the rocket?

[DruggedBunny]

Hi Mark,

Just because that's the only change I make, and for some reason, with LightType.Point it causes a huge pause here on first init, whereas changing to Spot doesn't.

(I did see that the setting of LightType did pretty much nothing, hence assuming it was something in the shader!)

Maybe it's a driver thing then? I just tried WebGL and it was slightly quicker. Weird...

The camera is actually doing that, ie. following a trailing point -- the tricky thing is that the target position the camera moves towards is based on the rocket's speed vector, so if speed is minimal/zero then it gets too close, but I've struggled to do anything better so far. (Efforts at normalising and multiplying that haven't gone well.)

Tried so many different ways, but it's all trial and error! Hopefully I'll get there...

[blitz-research]

Ok, just re-read initial post and saw bit about a changing the orb code - will try now!

[DruggedBunny]

I don't think that'll make any difference, as it defaults to Point, which seems to be fine for you... but definitely not here! However, I can probably pre-generate the light and hide it, as re-generating via toggle (O) doesn't create the pause.

[DruggedBunny]

Quick video -- note the pause at 5 secs, followed by toggling on/off without pause - warning, music playing!

Happens on every new launch -- tried creating a temp Point light at startup but it still pauses on creating the orb light. Should be able to pre-create the orb-specific light though...

Must be a driver thing!

[blitz-research]

Yeah, I can sort of reproduce I think, the orb takes about half a second to appear? But I think it's to do with shadows, if I set glow.CastsShadows to false it seems to fix the issue, can you confirm? Will have a closer look soon.

Are you also having issues where the rocket hits the ground and doesn't blow up, like collisions with ground are still not working 100%?

[DruggedBunny]

Ah, yes, correct! CastsShadow = False produces no delay whatsoever! (I have deliberately chosen to have it cast a shadow, though.)

Yep, definitely still hitting ground quite often and it's not calling the .Collided lambda, even though it actually bounces. (Would just note that there is a small speed check in the lambda, but even moderate speeds that should be causing collisions aren't doing so.)

[blitz-research]

Will have a look, point light shadow rendering could definitely be optimized anyway, even ignoring the slow init it kills performance.

[DruggedBunny]

Thanks, Mark. Not urgent for me, obviously...

Yeah, hope the collisions thing can be figured out, seems weird because it's clearly detecting them (as shown by bouncing), yet not triggering the callback...

[blitz-research]

Can you check rocket->ground collisions by taking out the rocket linear velocity check altogether? If I do that, collisions are of course much more sensitive but seem to at least be triggering at the right time.

Actually, I'm not sure a plain velocity check is really good enough here, you may have to check change in velocity instead, ie: acceleration (or in this case decceleration!).

The problem is if the rocket in the previous update was nearly touching the ground, then in the next frame it collides and ends up just touching ground, it's velocity (ie: change in position) will actually be very small wont it? In other words, 'current velocity' may not tell you all that much, it will be more likely to be 'bigger' the faster you were going before hitting something, but not guaranteed to be.

On Sun, Jun 10, 2018 at 12:11 PM DruggedBunny notifications@github.com wrote:

Thanks, Mark. Not urgent for me, obviously...

Yeah, hope the collisions thing can be figured out, seems weird because it's clearly detecting them (as shown by bouncing), yet not triggering the callback...

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/blitz-research/monkey2/issues/391#issuecomment-396008217, or mute the thread https://github.com/notifications/unsubscribe-auth/ADU3QlEovjec1kz0-ShZ7hkX8ViEDwSHks5t7GQigaJpZM4Uhgwm .

[DruggedBunny]

Ah... I think you're right! Definitely seems to trigger every time without the speed check...

[DruggedBunny]

That said, it still sometimes touches/bounces once before exploding!

[blitz-research]

Ugh, I think it happened once but I've been unable to reproduce it since - I really need a way to reproduce this reliably. Any ideas?

On Sun, Jun 10, 2018 at 2:21 PM DruggedBunny notifications@github.com wrote:

That said, it still sometimes touches/bounces once before exploding!

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/blitz-research/monkey2/issues/391#issuecomment-396014406, or mute the thread https://github.com/notifications/unsubscribe-auth/ADU3QiCPpV_B8EyJyMtzXnurJ2hz6be8ks5t7IKugaJpZM4Uhgwm .

[DruggedBunny]

Try hitting the ground nose-down at 45 degrees or more, or clipping ridges -- I find those bounce more than hitting with the bottom end, for some reason, which 'usually' explodes. But it is intermittent, unfortunately.

[blitz-research]

Ok, pushed a super dodgy fix that really shouldn't work but seems to work 'better' here.

I am finding the demo hard to control/test though - I managed to 'lie' the rocket down once I think but am struggling to do it again.

We'll need a more stable 'test-bed' if there are further problems. Some way to just reproduce the problem without the need for user input or indeed any skill on my part whatsoever would be ideal!

On Sun, 10 Jun 2018 at 9:12 PM, DruggedBunny notifications@github.com wrote:

Try hitting the ground nose-down at 45 degrees or more, or clipping ridges -- I find those bounce more than hitting with the bottom end, for some reason, which 'usually' explodes. But it is intermittent, unfortunately.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/blitz-research/monkey2/issues/391#issuecomment-396033690, or mute the thread https://github.com/notifications/unsubscribe-auth/ADU3QlMtkBzDjUWe23XDyVSJ1P4-jjgCks5t7OL1gaJpZM4Uhgwm .

[DruggedBunny]

I'm checking out latest develop... will probably be a while before I get to do it, but I think I could at least do something like a semi-automatic 'cannonball' mode where it repeatedly 'fires' the rocket at random angles/speeds, logging parameters as it goes, so that when it does bounce it might be possible to recreate the case.

BTW Are you finding it hard just because Thrust-type stuff is hard for many (even in 2D!), or for some other reason? (The camera doesn't help here, at least in close-up situations.)

Probably not much I can do, really, given I'm at my limits of competence, but if you're using keyboard, try it with an Xbox controller, as you then have analogue control and it's much better...

[DruggedBunny]

After 10-15 mins of playing, I haven't seen it bounce without exploding yet, and it normally would have, so latest develop is looking pretty good so far...

[blitz-research]

Cool, but what I'm most worried about is it exploding without bouncing, please keep an eye out for this!

On Sun, Jun 10, 2018 at 11:01 PM Mark Sibly blitzmunter@gmail.com wrote:

Ok, pushed a super dodgy fix that really shouldn't work but seems to work 'better' here.

I am finding the demo hard to control/test though - I managed to 'lie' the rocket down once I think but am struggling to do it again.

We'll need a more stable 'test-bed' if there are further problems. Some way to just reproduce the problem without the need for user input or indeed any skill on my part whatsoever would be ideal!

On Sun, 10 Jun 2018 at 9:12 PM, DruggedBunny notifications@github.com wrote:

Try hitting the ground nose-down at 45 degrees or more, or clipping ridges -- I find those bounce more than hitting with the bottom end, for some reason, which 'usually' explodes. But it is intermittent, unfortunately.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/blitz-research/monkey2/issues/391#issuecomment-396033690, or mute the thread https://github.com/notifications/unsubscribe-auth/ADU3QlMtkBzDjUWe23XDyVSJ1P4-jjgCks5t7OL1gaJpZM4Uhgwm .

[DruggedBunny]

Ha, will do... I "should" notice that...

[seyhajin]

Opportunity to close this problem.