[Mark]

I never kept track. Probably at least 30 small and medium sized point lights, 2 maybe 3 small spot lights in the whole map.

so far, its WIP

[Plagman]

I didn't say you tried to waste my time (I should hope not!), I just laid down some good things to check before reporting an issue to avoid wasting people's time in the future, as some (but not all) of my time was indeed wasted looking at issues that turned out to be basic asset problems.

To check normals I shine a light on the model using default material settings using eg. the shrinker, and if there isn't a nice highlight looking back at me that's how I know normals are fucked. I think what you're really saying is that all the exporters you're using don't work properly as far as normals and you should use the MD3 compiler's rebuild normals tools every time. Just do that. Make sure to export after, it's easy to forget with that tool.

There's not a fire hydrant model in the test map archive you sent me, there's a fire extinguisher, arcade machine, etc, and there's a Duke3D hydrant sprite in the map itself, but it doesn't have any assets. Should I be using the model from the regular Polymer HRP to look at this issue? Are there any other behaviors that aren't in line with what you're expecting with the new build that I should look at, either on that test map or the full project?

[Mark]

There are still a bunch of models that seem to illuminate ok until their normal map texture is enabled. Both guys that made them used Blender so it may be more of the same normals issues. I've been nagging them to go back a few versions when Blender and it's exporter wasn't having these issues. We'll see what happens. Thanks for the help so far.

[Plagman]

I know that I've modified several MD3 exporters that were out there to add proper support for normals and bounding box info, but it's possible the authors kept updating them without these patches.

But if your model is really lighting up properly when there's no normal map it means the normals inherent to the mesh itself are fine, and it might be the normal map causing the issue instead. Either way point it out and I can go take a quick look.

[Mark]

Many of them looked ok because they had their normal maps disabled. Earlier this evening I enabled all norm and spec lines in the def just so I can spot and make a list of all the problem models and missing textures from earlier testing. That large building front model is one of them. The other building front down to the right. I think a few smaller props. I think most will stand out as you pass them. Multiple people making the normal and spec textures using different programs have had different results. We need to standardize what works best. Some stuff is placeholders or WIP but feel free to run around the map and look.

IIRC Blender 2.49's exporter was updated by Drek. Not sure about anything after that. I don't use Blender so I'm not current with all that

[Plagman]

I'm not noticing any obvious problems after syncing your change and walking down the street, if I set max lights to a high number.

[Mark]

What I noticed was instead of the light illuminating smoothly over the model it would light only small sections and change with player movement with normal map enabled, becoming very directional.

I have to get out here for the night. talk tomorrow.

[Tea Monster]

The hydrant is the standard HRP hydrant. It was made by Steeevie, who is a Max guy. I don't know what method he used to get his MD3. I can ask him.

[Plagman]

The hydrant model looks fine to me, what are you seeing in the test map?

[Mark]

darn, I started taking screenshots of just the storefront models with and without their normal map textures but I ran out of time and have to head off to work. But the difference is night and day. Without the normal map the light spreads out smooth and even over the model. With normal map the light becomes pinched, distorted and directional. I'll have to wait til later this evening to PM you some pics. Its quite obvious.

[Tea Monster]

In the current build it dosen't show the error. In previous builds, if you looked at it from one angle, it would look hyper glossy, as if it were covered in water. If you walked around the other side, it would look washed out and flat.

It's damn nice to see that working now. Thank you for fixing that!

[deuxsonic]

Does anyone else run into this problem with Polymer? Sometimes it seems to occur at random where at other times it will always happen to certain surfaces (this is right at the start of NAM) and sometimes when levels are saved and loaded, additional surfaces may disappear.

[NightFright]

I know that Polymer "forgets" to draw floors and ceilings sometimes when you open a swingdoor, save your game and reload. If this is related to it, I dunno. What Polymer also doesn't like is when redlines are overlapping (under certain conditions at least).

[Tea Monster]

Any progress on the transparency bug?

[Danukem]

Tea Monster, on 07 July 2016 - 11:57 PM, said:

Any progress on the transparency bug?

Do they know which bug you are talking about? I've certainly had a lot of trouble with transparent sprites completely blocking the view of other sprites that should be visible behind them, if that's the one you mean.

[Tea Monster]

Yeah. we have a few models where there is a transparent surface where you can see the interior of a model. The first surface you see is transparent, but the second surface in line is invisible, so you wind up seeing straight through the model. Perversely, one triangle will show up, but the rest of the faces will disappear, so it looks like broken glass.

I've sent Hendricks an example earlier.

Secondly, forcing a parallax of 0.0 on the cabinet model didn't fix the green glitch.

[Danukem]

Oh, ok. What I was talking about is probably a different issue, then. I was talking about when you have two separate sprites, and the transparent completely blocks the view of the one behind it or at the same coordinates. I first notice this with a few mods I made in which frozen enemies have an ice shell sprite that spawns on them. When I first made the mods, the transparent shell still allowed you to see the enemy underneath. But in recent builds you can usually only see the shell, although sometimes the enemy sprite flickers into view.

The other common case where I notice an issue is when I try to have a piece of flaming debris (or something similar) spawn both smoke and fire as it travels. Despite the transparency of the smoke, you will generally only see one or the other (usually the smoke because the sprites are larger, which is ironic because the smoke is transparent and the fire is not).

[Mark]

TM and I are experiencing those issues too. I am attempting to adjust the offending sprites in the map to less than ideal positions to minimize the unwanted effects.

[Hendricks266]

We implemented cstat 1024 in Polymost to fix this for the Duke 64 mod. I don't know if it made its way to Polymer or not.

[deuxsonic]

NightFright, on 23 June 2016 - 05:06 AM, said:

I know that Polymer "forgets" to draw floors and ceilings sometimes when you open a swingdoor, save your game and reload. If this is related to it, I dunno. What Polymer also doesn't like is when redlines are overlapping (under certain conditions at least).

Actually, I've found that saving and reloading has a tendency to cause the problem to spread on the map or start it outright. I played through Duke It Out in D.C. recently and in addition to the sky appearing red instead of blue on Dread October and the Chaingun bug where it doesn't switch weapons if you get it down to 1 or 2 ammo and then run out, I run into this situation where sometimes I'm hesitant to want to save because I know that when I load it, the surfaces disappearing may spread. Yes, it does do it with swing doors sometimes, but actually the majority of the time it occurs elsewhere, where ceilings and floors (and sometimes both) and walls and other surfaces draw the sky rather than their proper texture. Since the sky is what gets drawn when this occurs, I'm curious what would be drawn on a map that had no ceilings or floors set to be sky, or if it would stop the problem from being able to occur altogether.

[Micky C]

No properly-designed map should have the disappearing surface issue. Mappers should be aware of how sectors such swinging doors move and if they overlap another sector.

I imagine it'd just show black if there's no sky set.

[deuxsonic]

Micky C, on 08 July 2016 - 10:53 PM, said:

No properly-designed map should have the disappearing surface issue. Mappers should be aware of how sectors such swinging doors move and if they overlap another sector.

I imagine it'd just show black if there's no sky set.

I'd agree except it happens on official maps. I don't know if those are necessarily properly-designed.

[Tea Monster]

I was actually talking about a model.

[TerminX]

deuxsonic, on 09 July 2016 - 05:41 AM, said:

I'd agree except it happens on official maps. I don't know if those are necessarily properly-designed.

There are some small errors present in the maps that came with the game.

[deuxsonic]

Isn't there some kind of "fix" console command? Would this have any effect on this problem?

[Danukem]

deuxsonic, on 09 July 2016 - 02:38 PM, said:

Isn't there some kind of "fix" console command? Would this have any effect on this problem?

I think mapster has a function for removing bad sprites, but there is nothing that would fix sector issues AFAIK.

[deuxsonic]

I was just thinking like I know some games are seemingly able to detect problems with maps and plug holes and things automatically without the user even knowing and thought maybe EDuke32 had something like that.

[Hendricks266]

The problem is that Polymer bails out when it doesn't know how to handle invalid geometry. Sometimes it only happens after a swinging door moves, and Polymer normally remembers the last known good geometry, but it doesn't get saved in savegames.

M210 mentioned something about a tessellator setting...

[Kyanos]

Tea Monster, on 09 July 2016 - 08:15 AM, said:

I was actually talking about a model.

I know exactly what you mean. I have some plant models I ripped from Turok (for someone else) that would never draw properly in Polymer.

The issue I find is when a surface has some alpha on the texture and line of sight happens to pass through that surface twice.

I can dig up example md3s if requested.

[Tea Monster]

I've sent Hendricks one we were having issues with. If you send one with screens, it may help.