Problem with eye candy

[KarenRei]

The normals certainly wasn't. It was correcting of broken normals. Broken, not as in "it is one person's opinion", but broken as in "these are outright wrong".

 

You were the one who made the decision to lump together a normal fix and the lighting changes into a single define, not me. In fact, when I realized that I hadn't ifdeffed them, I started grouping them into two defines, only to get a collision (with your single ifdef changes) when I did a cvs update.

Edited April 29, 2007 by KarenRei

[Learner]

The normals certainly wasn't. It was correcting of broken normals. Broken, not as in "it is one person's opinion", but broken as in "these are outright wrong".

 

You were the one who made the decision to lump together a normal fix and the lighting changes into a single define, not me. In fact, when I realized that I hadn't ifdeffed them, I started grouping them into two defines, only to get a collision (with your single ifdef changes) when I did a cvs update.

No reason you couldn't have split them up

[KarenRei]

Will do, then

[Entropy]

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...).

 

The reason we don't want the NEW_LIGHTS in this client is because it doesn't look good (I am assuming this is because it's not finished). For some reason, the shadows look too dark (which is BAD on snow maps, when the shadow map resolution is small), and the whole scene seems to be like overexposed.

 

I am not sure if what I am seeing is a bug or incomplete work, or maybe you think that looks better than the current light. However, both me and Roja do not like how that looks for the time being.

[KarenRei]

I saw Roja's screenshots, and the appearance is quite wrong (I told her as much). On the other hand, it does look correct for other people. It's actually shadow problems, which will probably be fixed when I fix the shadow bugs. They're just not stressed as much without the lighting. Re, with shadow mapping vs. with shadows without shadow mapping enabled.

 

Anyways, with normals separated from lighting, this is less of a major point for now. Assumedly, normal fixes go in this time, and (assuming it passes the Roja test) NEW_LIGHTING next time.

 

Back to working on fixing shadows, since nobody else seems willing to touch them.

Edited April 29, 2007 by KarenRei

[Learner]

I saw Roja's screenshots, and the appearance is quite wrong (I told her as much). On the other hand, it does look correct for other people. It's actually shadow problems, which will probably be fixed when I fix the shadow bugs. They're just not stressed as much without the lighting. Re, with shadow mapping vs. with shadows without shadow mapping enabled.

 

Anyways, with normals separated from lighting, this is less of a major point for now. Normal fixes go in this time, and (assuming it passes the Roja test) NEW_LIGHTING next time.

 

Back to working on fixing shadows, since nobody else seems willing to touch them.

I said you could seperate the normals, I never said anything about them going in for this release.

[KarenRei]

Okay, then we're back to "why don't you want your bugs fixed"? The normals are *broken* on tons of EL objects. It's not a subjective judgment; they literally are broken. And, are you planning to make EL flicker again as well?

[Learner]

Okay, then we're back to "why don't you want your bugs fixed"? The normals are *broken* on tons of EL objects. It's not a subjective judgment; they literally are broken. And, are you planning to make EL flicker again as well?

A black replace on the objects when they load is not where the fix should be. Talk to Roja so she can get the normals in the models fixed. Changing them all en mass at runtime is a hack!

[Entropy]

What we should do is make an add on to the object covertor to fix them, rather than fix them at runtime, which is hackish and slow.

[KarenRei]

It distinctly is not slow. I challenge you to demonstrate any sort of perceptible slowdown. You could run this each frame and still not get a framerate drop. 99% of the time in loading a 3d object is spent reading it from the disk. Doing a few simple math operations per poly (that's all it takes to compute a normal) is nothing compared to the time it takes for a hard disk to read sectors.

 

I suppose the fix for flicker is to manually track down each spot that flickers too, right?

 

To get a list of every object that has broken normals would require writing a piece of code that loads every object, then determines the proper normals, then does a comparison routine to see if the reported normals are close to the actual normals, then assembles a list of objects that are broken. Then we'd pass that broken list to Roja, who'd have to manually load and resave each one of those. You're talking five times as much code and fifty times as much labor. For what? To prevent a mythical slowdown? On a bug that I already have fixed?

Edited April 29, 2007 by KarenRei

[Entropy]

Usually the files are not loaded from the disk, they are loaded from the cache (especially with computers with a lot of RAM).

And like I said, the solution is to put the whole thing into an EXTERNAL program, rather than do it at runtime.

 

Anyway, arguing about this won't solve anything, so let us each worry about our code instead of arguing like this.

[KarenRei]

Sectors are only cached after they've been read. Even still, calculating a normal is faster than even loading from disk cache because of cache overhead and because normal calculation is largely dealing with CPU cache, not main memory.

 

Want a performance increase on object loads? Take normals out of the objects altogether. Any shrinking of the object file will pay off several times over in terms of performance. There's no good reason to have the objects already have their normals, because that's just extra data to load, and it's faster to compute than to load. But that is neither here nor there.

 

Sorry about getting all up in arms about this, but there's nothing that's more frustrating than *fixing bugs* with *simple fixes* with *no negative consequences* and being told that we'd rather just have the bugs.

 

As for each of us worrying about our own code, back to fixing shadows, since nobody else will (i.e., somebody elses code )

[Entropy]

You might be right about the normals being faster if they are calculated on runtime rather than being loaded from the disk.

However, I have some doubts (many SQRTs are needed for that, and the SQRTs are slow). Nevertheless, we will have to do some tests AFTER THE UPDATE, and determine which is faster.

 

Speaking of special effects, were you able to determine why the fire looks bad? And one additional question: How many lights can the special objects take from the scene? That is, is there a max number of lights allocated for the eye candy stuff? If no eye candy is in use, will those lights return to the scene lights?

[KarenRei]

There's a fire fix in; you might want to try it out. There were some issues with size not changing properly with reductions in LOD, and because I had no FEs, I had been largely just testing with F9 fires, not campfires as well (someone game me some FEs for testing this time around). It was one of those issues where it worked fine for me in my test cases, but my test cases weren't elaborate enough.

 

Eye candy currently uses 3 lights. It is not currently set up to yield them back if eye candy is disabled, although that could be coded in. It could also probably get by on two if we were having a shortage of lights elsewhere, but the eye candy lighting would be less even.

Edited April 29, 2007 by KarenRei

[Entropy]

Ok, well, it's too late to change this now, but after the update it would be nice if the unused eye candy lights would be returned to the scene.

 

I will test the new fires tomorrow, and let you know how it works.

[KarenRei]

Sure thing -- just let me know.

[KarenRei]

Ent or Roja: Quick question for my work on shadows. Do you have the "Shadow Mapping" option checked?

[KarenRei]

Well, I'll be... I just checked out a 120 day old client, turned on shadows but not shadow mapping, and guess what? They're funky. I accelerated time, sitting on IP near the beam, and you can watch the shadows from the ridge move in opposite directions as the shadows from the tree.

 

Looks like we've had shadow problems of some type or another for a long time... My work so far has revealed a number of problems (I've probably got the crashes fixed in my current version, not checked in yet), but this is one I never would have guessed. I always used to use the shadow mapping flag.

Edited April 29, 2007 by KarenRei

[Entropy]

The non shadow map shadows are buggy and always were (they are projected to the ground only, which causes ugly things to happen when the camera is rotated or when you move).

I think that we should get rid of them some time in the future.

[sanlay]

I noticed something in Palon storage.

I have a small drop in FPS (60 to 50), but above all, a large load in CPU (from 30% to 96% CPU usage).

The fountain effect seems to be the reason as it's destroyed only at a certain distance, no matter if you can see it.

Is it possible in the future to add culling for eye candy?

[Roja]

Yes I had shadow mapping on.

 

-The new fire looks better, but still things to improve it:

1. Make the flame part larger, both in radius and in height.(right now it's hidden in the firewood, you can't see much of it)

2. The smoke is still WAY too black/thick...decrease the particles there, and decrease the opacity to almost transparent and make it gray instead of black.

 

Here is a mock-up i did to give you a better idea of the size & smoke:

http://img.photobucket.com/albums/v59/ffle...fireconcept.jpg

 

 

-The Torches fire

1. Get rid of the halo circle(this is a cool effect but it just doesn't look right for a torch)

2. Make the edges of the fire ball area more orange/red. Right now it's all a bit too yellow overall. So jsut a bit more added to the edges and that should do it.

 

-The candle flame

1. Get rid of the halo

2. The small sparks that fly off from the flame kind of spread out as they move away..it looks more like a magic fire than a real flame. The flame should be very small and concentrated in once place. No sparks are needed. In fact, if you look at the old candle flame particles, before the eyecandy, that is more of what it should look like, so use that as a model; perhaps just make it a little more opaque in the center.

[KarenRei]

Ent: Thanks for the info.

 

Nolgrim: Culling is too complex of a thing to implement before release.

 

Roja: Can I get a new screenshot of a fire with too much smoke from you? Thanks for the mockup, by the way. Also, can you take the screenshot with and without point particles? Thanks. I want to make sure that we're seeing the same level of smoke.

 

Size changes: Only applies to regular fires? Or F9 as well?

 

Torch halos: The same effect is also used for candles (smaller scale). You should check them out too before I start modifying the effect.

 

Orange/red: I can try. It can be a bit tricky sometimes, as the blending is additive RGB, but we'll see what I can do.

[Roja]

no problemo...here's the shot

http://img.photobucket.com/albums/v59/ffle.../test_fire2.jpg

 

If it comes down to it the torches & candle flames can use the old particles, as I was happy enough with them. They looked good.

 

f9 fire size is fine.

 

Edit:-also the normal smoke particles(without the fire attached) are way too black, way too thick, and they spread out too much.

 

Edit#2: I LOVE the fountains, but as someone else mentioned, they are too gray. Change that gray to blue and that should be good to go.

[KarenRei]

(working on these)

 

Smoke: Which smoke effects are you looking at? There are a number of different smoke effects in EL, and I had to guess at how intense to make each one.

[Roja]

Here we go, in order from left to right:

smoke, smoke1, smoke2, smoke3.

New on top. Old particles on the bottom.

 

Obviously the old ones need work...but so do the new.

 

http://img.photobucket.com/albums/v59/ffle...test_smoke1.jpg

 

I think what you can do is

1. make it gray

2. make it much less opaque

3. make it fade out more

 

Edit..mock-up of more ideal smoke:

http://img.photobucket.com/albums/v59/ffle...test_smoke2.jpg

 

from left->right

same order as above except last one is smoke_big.

smoke-just a general smoke.

smoke1 is like a smoke you'd see above a pot boiling or cooking something. So this should be small and quick moving, and not as opaque as the other ones.

smoke2 is like a small chimney smoke

smoke3 is like a larger chimney smoke

smoke_big is a large thick smoke.

 

The colors of the smoke should start with a medium gray, and the color should vary but only slightly. So some lighter & darker shaded particles can be thrown in there.