[High Treason]

I wonder if changing the model's sectnum to the player's sectnum would work? You could limit the range with ifpdistl to make it more efficient.

[Fox]

Diaz, on 16 November 2012 - 04:42 AM, said:

Alright, there's something I've noticed now that I'm starting to use lots of models for details.

If the sectnum where a sprite is placed is not directly visible, the sprite won't be drawn. This is good and helps performance, but sometimes I'm using big models that span across more than one sector; and if the sector where the "center" of the model (the sprite) is located is not visible, the model will disappear, even though the player is still looking at one of the sectors the model "occupies".

Would it be possible to add some sort of .def flag so models are always drawn? I guess we could turn them into actors and code them to change cstat to visible or invisible when the player is far enough or inside a certain sector where no parts of the model are visible, so performance is not hindered much.

Below are a couple of pictures of what I try to achieve - some models disappear here when the player looks in certain directions, at certain places. It's not something terrible, but would look neater if it didn't happen! />

First of all, these screens are very impressive. There is a quality standard, and everythings fits together, and on top of it the atmosphere.

About the sector problem, it doesn't relate much with performance as it does with how the structures are rendered. The game will first determine whenever the sector is visible or not to determine if it should draw the sprites.

But I agree that there should have a cstat so a model won't depend on the sector. However keep in mind that it won't work well with "false ROR", since two sectors would occupy the same space.

[Plagman]

This is also going to be fixed in the future, but an "always draw" flag isn't the answer here. Technically it's an error to make a static model that extends outside the bounds of its sector, but I know that it's too restrictive in practice so I'll implement more zealous discovery of sprites based on the model bounding boxes.

[Diaz]

As always, great stuff to hear, Plagman. So many things planned for the future, the engine's gonna rock more than it does already

That and some per-poly collision (or simpler collision meshes, as most engines use) and we will have total artistic freedom.

[RichardStorm]

I don't know if it's a known bug, there is something new to know on polymer spot lights, or is an issue by my video card drivers, but i noticed that from a certain release (a couple of months ago) polymer lights don't cast shadows properly: for example lotag 50 SEs i put in some test maps no longer work, and light from maphacks don't work well (like in front of the cinema in E1L1, it cast shadow only when the player is in certain sectors).
Anyone noticed the same thing ?

/EDIT: This happens while running the vanilla duke without HRP, doesn't matter if with/without CON or DEF modifications.

[Diaz]

Not sure about your test maps (you could check if you have pressed "1" on them to make them one sided, that disables shadows now) but the HRP maps seem fine to me.... the light in front of the cinema was fine.

[Diaz]

Keyboard input is broken as of latest snapshot - I can't move!

EDIT: Alright, it's fixed!

[Fox]

Is it possible to add a command that calculate the area of a sector? I suppose the value could get a little too big, so even the square root of it would be good.

[Plagman]

DT posted code to do that a few days ago, so I suggest doing some archeology.

[Danukem]

Plagman, on 21 November 2012 - 08:02 AM, said:

DT posted code to do that a few days ago, so I suggest doing some archeology.

I do have some code that sort of does that, but I don't recall ever posting it. Maybe it was Mblackwell?

EDIT: Here is a formula that does it properly, which can be implemented in CON

http://www.mathopenr...olygonarea.html

[Plagman]

Yes, it was MB, and it was to calculate the sector's center.. my memory clearly isn't what it used to be.

Now, you'd also need to calculate the area of any islands inside the sector and substract it from the area of the outer edge.

[Diaz]

A quick question about Polymer - are soft shadows calculated on the CPU?

It seems areas that relied heavily on shadow are as slow on my new videocard as they were on the old one. Resolution, normal and parallax mapping performance have obviously improved, but not shadows...

[Plagman]

Not on the CPU, but walking the map to be rendered from the point of view of the shadow is pretty costly. That's the main weak point of the renderer perf-wise, and the first thing I intend to tackle.

[Diaz]

And rendering the map from the point of view of the shadow is like rendering it multiple times (just like lights do), I assume? So it puts stress on both the CPU and GPU depending on the amount of load the scene has on either?

[Mark]

Some of you may have already discovered this. But if you haven't, I was messing around with different settings of various things to increase framerate. Using Polymer, one thing I found out is there is little or no difference between enabling or disabling all the normal and spec maps for my 40 custom texures and models. There are a few HRP textures with normal and spec maps still running because it was too much trouble to disable those too. But I think there would still be no difference with those shut off too. Just something to keep in mind when mapping.

[Hendricks266]

^ Yeah, maps themselves were designed to be ultra cheap, perf-wise.

[Plagman]

Diaz, on 24 November 2012 - 01:07 PM, said:

And rendering the map from the point of view of the shadow is like rendering it multiple times (just like lights do), I assume? So it puts stress on both the CPU and GPU depending on the amount of load the scene has on either?

Lights need to redraw stuff that's already known to need to be rendered. Shadows need a full new scene from another point of view, so you have to figure out what to render all over again; that's why it's so painful. Right now all planes on the map are in disjoint buffers so each rendered wall is a different draw call, which is pretty heavyweight on the CPU. I have a local tree where the whole map lives in the same buffer, so you can render several planes in a single draw call by constructing the right index buffer, assuming they share the same material. That means for regular map rendering it'll do all the walking without drawing anything at first, then sort planes by material used and render them as batched, which should be a lot better. For shadows you don't need materials at all (unless you want "cardboard cutout" shadows for sprites, so these will have to have a special flag and be rendered in their own call, still), so we'll be able to do shadows in a single draw call, which should help tremendously.

[Diaz]

Mark., on 24 November 2012 - 01:09 PM, said:

Some of you may have already discovered this. But if you haven't, I was messing around with different settings of various things to increase framerate. Using Polymer, one thing I found out is there is little or no difference between enabling or disabling all the normal and spec maps for my 40 custom texures and models. There are a few HRP textures with normal and spec maps still running because it was too much trouble to disable those too. But I think there would still be no difference with those shut off too. Just something to keep in mind when mapping.

It all depends. Normal and specular maps affect fillrate, so if you have a crappy videocard, disabling them improves performance if you're being limited by fillrate. If you have a lot of Polymer lights in an area with many normal maps, those apparently will have to be re-drawn many times so performance will drastically decrease. My 8800GT ran some areas at like 20FPS with normal maps enabled and disabling them would make the same area run at 60FPS, until some other bottleneck is hit.

[Diaz]

Thanks for the explanation on shadows, Plagman. Looking forward to improvements

[Fox]

Phew, I got a problem when using a custom palette with Eduke32.

Comparison beetween 8-bit and OpenGL modes:


Basically the last 15 colors are hard-coded to glow in the dark, and there is nothing I can do about it.



I don't really get why this is hard-coded, since it would make a lot more sense to have a standard .def file in Eduke32 for this sort of thing.

[Plagman]

Try r_fullbright 0?

[Fox]

Thanks, that solved the problem.

But I don't think that it should be only in the cfg file settings, since they are supposed to be superfluous.

[Plagman]

Yeah, it should probably be a knob.

[Mark]

Diaz, on 24 November 2012 - 02:29 PM, said:

It all depends. Normal and specular maps affect fillrate, so if you have a crappy videocard, disabling them improves performance if you're being limited by fillrate. If you have a lot of Polymer lights in an area with many normal maps, those apparently will have to be re-drawn many times so performance will drastically decrease. My 8800GT ran some areas at like 20FPS with normal maps enabled and disabling them would make the same area run at 60FPS, until some other bottleneck is hit.

Then I guess for now my Nvidia 9800 GTX card is still chugging away decently. By the way, my comparison was with that FPS sucking, shadow casting flashlight mod running and 22 point lights in the visible above ground areas. A lot more underground but they are isolated from the above ground areas by ceiling doors so I'm not counting them.

[Helixhorned]

Fox, on 24 November 2012 - 02:35 PM, said:

Basically the last 15 colors are hard-coded to glow in the dark, and there is nothing I can do about it.

There is now.

r3230 said:

Expose per-tile nofullbright bit (GL modes only) to DEF.

The attribute is set per tile from DEF: either
nofullbrightrange <begintile> <endtile>
or
tilefromtexture <tile> { ... nofullbright ... }
As a special case, the list may only contain "nofullbright", in which case the
texture is not changed. (This is analogous to "texhitscan".)

Example:
// make piggy's eyes fullbright red only when it fires the shotgun
nofullbrightrange 2000 2034
nofullbrightrange 2040 2049
nofullbrightrange 2055 2061

Quote

I don't really get why this is hard-coded, since it would make a lot more sense to have a standard .def file in Eduke32 for this sort of thing.

It's hardcoded because these colors are fullbright in the default classic shade table.

[Mark]

Sorry for not going to my original thread for this, but I couldn't find it after a few minutes of searching. This is about problems with the normal maps in some of the HRP textures under Polymer lighting. My original post showed a pic of an SE49 point light not casting an even shadow on floor, wall and ceiling. It turned out to actually be a problem with the texture's normal map. I re-made the normal map it and the problem went away. I found some more while mapping today. So far tiles 349 -- 742 -- 757 -- 1189 seem to be affected. There may be more but I haven't run across them yet. Its an odd thing. If a wall with one of these textures is lit up, approching it from one side it is lit up properly. Approach it from the other side and it is not. A one-way normal map.

[supergoofy]

Something that came to my attention:

http://code.google.com/p/qeffects-gl/

I don't know if it will work with EDuke32, I haven't tested it yet.

[Diaz]

^ It doesn't for me. Eduke32.exe won't even launch with that dll.

[Jblade]

I remember there was a OpenGl dll that did work a long time ago, although it had to be manually activated. This was long before the days of Polymer though. It was ok, but just slapping Bloom over the screen looks terrible, it's only really effective when you have control over it.

[MusicallyInspired]

I remember trying that out ages ago. I used it with HL1 too. But for EDuke32 it would bloom the screen, but there would also be a smaller version of the screen in the bottom right corner taking up about a quarter of the screen and it was un-bloomified. Something like that. Results were terrible.