Slowdown on node creation

[JP]

Hello!

So in my project I'm working on I've seen some short hangs when I create an object for the first time...

I preload the textures assigned to the nodes by doing the following:

driver->getTexture( <path> );

But is that not enough? Does that just load the textures into RAM and not actually send them to the GFX card and that's what's causing the hang? When I create subsequent objects there's no hang at all so i'm assuming it's something along these lines....

I've seen this issue with cube scene nodes with a billboard scene node attached (both textured) and with a particle system.

Any suggestions would be great!

[hybrid]

getTexture loads the data to the GPU for sure. Sounds as if some larger memory allocation happens somewhere. Huge particle systems can be a problem. Or any other huge array.

[JP]

Hmm.. it's all fairly simple stuff... I'll try and see if there's anything obvious that I might be doing at the same time... If not then I could try and make a minimal example for analysis

[bitplane]

Rather than going to all the trouble of profiling it, just hit the pause button in your debugger while it's hanging. Repeat a couple of times to be sure, 9 times out of 10 you'll stop inside the offending code!

[JP]

Good tip bitplane, might help out!

[JP]

Aaaaad 18 months later...

Can't remember what project I posted this thread about but I've come across the same issue again.

I've got a 4096x4096 texture and during, what is presumably the first call to, driver->draw2DImage it hangs for a loooong time (3-4 seconds I think).

Any more ideas why this might be? I'm running irr 1.7.1.

I'll try hooking up a debug build of irrlicht to see where in draw2DImage it's hanging.

[fmx]

So you're finally back on the forums, cool

That problem sounds like your hardware is struggling to load the massive 4096 texturemap.
If it loads faster with a smaller texture (eg, 512 or 1024) then you probably need to consider changing the system in your app to use multiple smaller textures instead of a single uber large one

[hendu]

Well, profile it, and show us which line takes that long.

[JP]

Smaller textures had a much smaller hang. 1024 textures had no perceivable hang. Using multiple smaller textures might be a possible solution i suppose...

I didn't get anywhere with the debug build of irrlicht as i couldn't get my game to load the irrlicht debug symbols, have had it working before though i'm sure...

In the end I went looking around and found it's a problem others have had with OpenGl and have solved it by hiding the stall behind a loading screen by doing the first render underneath it. That worked for me but the multiple smaller textures may be a more suitable fix I'm thinking...

[hendu]

Oh, you have a driver that's trying to be clever? Nvidia I guess

Yes, some drivers delay loading until absolutely necessary, ie the first render using that.

solved it by hiding the stall behind a loading screen by doing the first render underneath it. That worked for me but the multiple smaller textures may be a more suitable fix I'm thinking...

Nvidia themselves recommend that solution. So better use it rather than use worse textures

[JP]

My thought was not to use a single smaller texture but multiple smaller textures so instead of a single 4096 texture I'd use 4 1024 textures or something, the 4096 texture is for a 2D character sprite sheet so only part of the texture is used each frame. For that reason splitting the texture into smaller chunks would be ok.

Having said that it would be more effort to do that...

Good to hear that only certain drivers do it... it's happening on my laptop but that's not the target hardware so it might be ok there..

[Nadro]

You can also use a compressed textures REDDemon did a nice implementation for KTX.

[JP]

Yeah I should look into those, I assume they remain compressed in memory?

[Nadro]

Yes, they remain compressed in memory.