Problem with eye candy

[Tanyia]

I have to say I agree. The campfire at beam is like a black column, same with the F9 fire. A little touch of smoke rising out of the flames would look superb--the flames already look fabulous.

[KarenRei]

Please, not everyone at once. The fire is something else altogether. I just got a screenshot from Roja demonstrating it, and it looks really messed up. I don't know when it got messed up like this, but let me assure you that this is NOT what it's supposed to look like. I'll try and reproduce that tonight. Please don't go in with solutions like turning down the rate of smoke particles. The problem is that the particles are too big for their alpha, and it's undoubtedly affecting more than just smoke. You're probably not getting the sparking, the texturing of the smoke, and all of that other stuff, either.

 

Entropy: I'm not opposing having a configurable level of detail, by any means. I'm opposing having a *fixed* configurable level of detail. Trust me -- you'll make the problem worse by locking the LOD in place, even if you lock it at a "low" level. What I'm saying that you want is a configurable *adjustable* LOD. I.e., instead of "low/medium/high", you want to be able to set "Minimum eye candy framerate" and "Maximum eyecandy framerate". If you're above the maximum, it's full detail. If you're below the minimum, it's minimal detail. It currently works like this, except the min and max are locked in place. I don't have time to code it right now with these other problems that have sprung up, but I've pointed out several times on the forum how it would be done. If you really want a "low/medium/high" we could map it to min and max framerate pairs (say, low=40/80, medium=30/60, high=20/40), but why constrain people to that?

 

So, you've updated since the last commit? Something is messed up here (esp. given how wrong the fire looks in Roja's screenshot), and I'm going to get to the bottom of it. For now, go to a spot that's slowing you down abnormally, log out, uncomment line 1641 of eye_candy/eye_candy.cpp (a std::cout statement printing things like the framerate and the change LODs), rebuild, log back in, and give me the spammy output that it prints (all of it, if you can). I only need a few seconds worth of debugging info.

 

In the future, everyone, please post Eye Candy-related bugs on the programming/Special effects thread, or at least message me that you started a new thread, so that I can respond before the complaints turn to a dull roar . I had been watching that thread, and was pleased that there had been no bugs reported in a while (consequently, I was spending my time on the map editor instead). Sure, I'll stumble into threads elsewhere eventually, but when time is critical, I'd rather not delay

Edited April 26, 2007 by KarenRei

[Entropy]

The reason I posted it here is that other people that don't usually go in the programming forum can see this thread and post their problems here. IMHO, that other thread should be mainly for programming specific stuff, like new effects, etc.

 

Anyway, Roja's fire looks a little different than mine because she has an older laptop (Ati 9600 mobility) which doesn't support point particles.

However, my smoke (and other's smoke) is also very black and high, it looks like you are burning a tire in there, not wood

 

As for the dynamic AND fixed LOD, that's fine with me. The way it should work is like this: Under optimal conditions, there will be no more particles than set in the level of detail. Under not so optimal conditions, it should go lower.

[The_Piper]

I see the fire with both yesterday's build I made and with one that is about 3 days old. I really hate to ask this but are you sure there was a fire lit? (And were you using the client I made?)

 

The fire was lit because i tried to light it and got the message, its already burning (cant put a FE on it). It was the campfire at beam, which was burning when i logged in on my older client (meaning, i could see flames with the older client).

 

And i havent tried your client, im using self compiled clients under Linux

 

Piper

[Roja]

Piper, make sure your directory looks like this:

textures/eyecandy/128x128

(and all the others 16x16, etc, should be in that dir too)

[KarenRei]

It should be the same with or without point particles. Something is really wrong, so I'm going to try and figure out what it is this evening.

 

Once again, anyone who has problems with performance should go somewhere that they had problems and follow the directions that I gave to Entropy to give me debugging information.

 

I'll follow this thread from now on, then, too.

Edited April 26, 2007 by KarenRei

[The_Piper]

Piper, make sure your directory looks like this:

textures/eyecandy/128x128

(and all the others 16x16, etc, should be in that dir too)

 

Bingo, that was my problem, i see fire now \o/

 

(My folder structure was textures/eye_candy/textures/128x128 etc.).

 

Thanks!

 

Piper

[Entropy]

Karen, can you please post a screenshot of your fire, so that we can see how it is supposed to look?

 

Mine looks like this:

http://www.eternal-lands.com/fire_bug.jpg (real fire and F9 fire)

[KarenRei]

Once I get home, sure.

[KarenRei]

Sorry for the delay; I didn't have as much time last night as I expected. I got started on some of the necessary changes, but only have partial fixes in so far. I did get the feature to be able to set your max and min eye candy framerates, though.

 

Any performance-related debugging info for me?

[ttlanhil]

I don't have much debugging info, but I did find something odd...

I was getting slow map-change times, a couple of seconds at the end of loading (full bar)

so I went into options to turn off eye-candy, but I missed and got SFX off instead... and not only does the map-loading go at proper speed now, but I think the normal eye-candy stuff is having less of a performance hit (subjective, not definite)

maybe you could improve performance during effects by cleaning something in SFX

 

ed: scratch that, SFX is still off, but the map-load delay is back... it may have been related, may have just been coincidence

Edited April 27, 2007 by ttlanhil

[Roja]

Um, I can try to help maybe. Is this ALL I need to do?

 

"uncomment line 1641 of eye_candy/eye_candy.cpp"

[Cycloonx]

This is how fire should look (Left one is ok, right one is fucked up) and my PC graphics card and CPU aren't that big.

 

[KarenRei]

Cycloonx: Yes, I know about that. It's an issue related to level of detail. As I just mentioned, I didn't have enough time last night to finish fixing it. Thankfully, today is Friday, which means a weekend coming up.

 

As a note, adding the ability to change your min and max eye candy framerates makes this a lot easier to debug, because I can adjust the level of detail I'm getting. I normally would have to go to my PC to get high LOD because my laptop's vid card is awful at rendering the non-eye candy parts of EL (annoying intel chipsets ).

 

Roja: You'd have extra trouble because you're a Windows user, so you can't see output printed to stdout ("standard output"). I could make a debugging statement that would work for windows, but it would be extra effort. Also, this is only for people who are experiencing problematic slowdowns -- are you?

[Alia]

I don't have much debugging info, but I did find something odd...

I was getting slow map-change times, a couple of seconds at the end of loading (full bar)

 

I noticed similar behaviour when i compiled client with -DNEW_WEATHER and -DNEW_LIGHTING.

And I think it happend when there were a lot of shadows. Though I'm not sure. (Edit: no, problem is not with shadows, cannot repeat it)

Now it is night on test server and I change maps without any delay

Edited April 27, 2007 by Alia

[Cycloonx]

Cycloonx: Yes, I know about that. It's an issue related to level of detail. As I just mentioned, I didn't have enough time last night to finish fixing it. Thankfully, today is Friday, which means a weekend coming up.

 

Yes I know, but that picture was for the guy asking how the fire should look. I didn't want to annoy you

[Entropy]

Ok, one other note for EVERYONE testing:

 

Do NOT include the new weather and new lights in this client yet. Those two options are not going to make it in this client for this update, and they should be tested after the update is OK. Otherwise there will be all kind of problems and would take a lot of extra time to fix them. It's almost May and we don't have a RC yet.

[ttlanhil]

if I may ask... why not? new_lighting is quite new and not that well tested, no arguement there, but new_weather isn't that new, I was under the impression that support for snow and such in new_weather would be included in the coming client

[Entropy]

Because the server isn't prepared for that yet, and therefore it hasn't been properly tested.

[Entropy]

It would also seem that the fire is not the only problem. For example, the fountain in WSC, with the eye candy OFF, I get ~27 FPS

Eye candy on, only 21 (so about 25% lower FPS for just one particle system).

[Cycloonx]

It would also seem that the fire is not the only problem. For example, the fountain in WSC, with the eye candy OFF, I get ~27 FPS

Eye candy on, only 21 (so about 25% lower FPS for just one particle system).

 

 

The same goes for the old particles and they looked even less special.

[KarenRei]

Please don't report performance drops without the debugging info that I requested. I cannot help you without it.

 

However, a 25% performance drop for a fountain effect isn't that extreme. We're doing 3d math on thousands of particles, transforming them to viewing space, then rendering them with texture maps using alpha blending. To not expect a performance drop is a bit unrealistic. The only way I could reduce the particle counts further without sacrificing quality would be if Roja wanted to make some "falling water" textures so that I could have each particle appear to be multiple particles.

 

Also, now that I implemented the ability to adjust your min and max framerates for LOD changes, if you decide that it is too much of a performance drop, you can change your criteria for where it reduces LOD. If just a min and max isn't enough precision, I could modify it further to let people choose specifically at what framerate to go to each of the ten possible levels of detail. That would probably need its own tab, though.

 

Oh, and while NEW_LIGHTING is newer than the start of the feature freeze, it doesn't require server changes. Still, it is new, so the "no new code during feature freeze will go in the next client" rule applies. Even though it's purdy, and part of it is just fixing EL's broken object normals (in the same way that the flicker fix I added after feature freeze fixes flickering, although you don't see anyone arguing to disable that...).

Edited April 28, 2007 by KarenRei

[Learner]

Please don't report performance drops without the debugging info that I requested. I cannot help you without it.

 

However, a 25% performance drop for a fountain effect isn't that extreme. We're doing 3d math on thousands of particles, transforming them to viewing space, then rendering them with texture maps using alpha blending. To not expect a performance drop is a bit unrealistic. The only way I could reduce the particle counts further without sacrificing quality would be if Roja wanted to make some "falling water" textures so that I could have each particle appear to be multiple particles.

 

Also, now that I implemented the ability to adjust your min and max framerates for LOD changes, if you decide that it is too much of a performance drop, you can change your criteria for where it reduces LOD. If just a min and max isn't enough precision, I could modify it further to let people choose specifically at what framerate to go to each of the ten possible levels of detail. That would probably need its own tab, though.

 

Oh, and while NEW_LIGHTING is newer than the start of the feature freeze, it doesn't require server changes. Still, it is new, so the "no new code during feature freeze will go in the next client" rule applies. Even though it's purdy, and part of it is just fixing EL's broken object normals (in the same way that the flicker fix I added after feature freeze fixes flickering, although you don't see anyone arguing to disable that...).

Then I guess I need to go find and disable that code also!

[KarenRei]

I've only mentioned it about four or five times in the past month, mostly in conversations with you. Surprised you're just now noticing.

 

I really don't get why you're so obsessed with getting rid of *bugfixes*, Learner.

[Learner]

I've only mentioned it about four or five times in the past month, mostly in conversations with you. Surprised you're just now noticing.

 

I really don't get why you're so obsessed with getting rid of *bugfixes*, Learner.

The lighting and normals was much more then a bug fix. It was a total change of how the client was handling things. Not something minor like adjusting the z pos slightly.