[Danukem]

Changed the thread name. Got tired of seeig "death of Polymer" when I'm still using it and it's getting fixed now.

[Mark]

My artistic sensibilities have been compromised. Yeah, my thread title doesn't fit any more.

[Hendricks266]

Tea Monster, on 10 June 2016 - 10:54 AM, said:

There is a transparency bug that is interfering with one of our models. Can I send it to you?

Sure.

Trooper Dan, on 10 June 2016 - 12:48 PM, said:

Changed the thread name. Got tired of seeig "death of Polymer" when I'm still using it and it's getting fixed now.

Changed it again. I can't help a good reference.

[Hank]

Trooper Dan, on 10 June 2016 - 12:48 PM, said:

Changed the thread name. Got tired of seeig "death of Polymer" when I'm still using it and it's getting fixed now.

You willingness to alter other peoples titles and posts, just because you are able to do though, through technical means is fucking irritating

[Danukem]

Hank, on 10 June 2016 - 06:54 PM, said:

You willingness to alter other peoples titles and posts, just because you are able to do though, through technical means is fucking irritating

I have never altered anyone's posts or [personal] titles. You are confusing me with someone else.

Why would you get offended if I change the title of a thread to more accurately reflect reality?

[TerminX]

Sometimes I change people's user titles just for a laugh. Internet forums are super serious business!

[Plagman]

Tea Monster, on 10 June 2016 - 02:57 AM, said:

There is no parallax used with that model and it isn't declared in the def file.

It's the same effect and map as the normal map though, so it could be applying even if you don't realize. Forcing parallax scale on that skin would probably tell you.

[Tea Monster]

I'll test that in a bit. Hendricks, I've sent a link to a file with the transparency bug.

Thanks again!

EDIT: One more thing. Is it possible to remove the sector visibilty 'feature' that makes a model disappear if the player can't see the sector that model is in? We were thinking of using a model to add to one of our set-pieces. Every time we turn around, the building disappears.

[Plagman]

There isn't code that tries to remove sprites if the sector is invisible, it's the opposite, where only sprites for sectors that are drawn during drawrooms() are scanned and queued for animation and rendering. What needs to happen is decoupling sprite scanning from the world pass to some extent, and tie it to the actual dimensions of sprites and bounding boxes of any associated models. A lot of that work is already done as part as dynamic light culling, eg. the model bounding boxes are already computed, but it never got hooked up to sprite scanning.

[Mark]

Somebody, I forgot who, made a con hack to accomplish what he wants. But during testing I found that some models ( I think ones that were either wall or floor aligned ) had a noticable shake in the game. It never went any further. Plus it was global and not adjustable to only certain models.

[Tea Monster]

If there was some way to flag it in the def file as 'always render' so only level geo was excepted.

[Tea Monster]

Gloss maps are working on user-spec tile models. Let me qualify that - they are showing up and are visible. They never seemed to work properly - at least compared to how other soft treats them.

[Hendricks266]

Where are they stored? Which channel of which other image?

Edit: I have been informed they are the alpha channel of the specular map. In that case, make sure you aren't using any PNG optimizers on your maps.

Beyond that, I have no knowledge of how the various mappings are supposed to work and I have not touched that part of Polymer before. Plagman might be able to diagnose the issue from screenshots.

[Hank]

Hendricks266, on 13 June 2016 - 04:49 PM, said:

Where are they stored? Which channel of which other image?

Edit: I have been informed they are the alpha channel of the specular map. In that case, make sure you aren't using any PNG optimizers on your maps.

Beyond that, I have no knowledge of how the various mappings are supposed to work and I have not touched that part of Polymer before. Plagman might be able to diagnose the issue from screenshots.

gloss maps are essential nowadays for PBR based textures (at least for the Cryengine) . I never seen any support for actual gloss maps in EDuke32, at least not as per the wiki.
Reference:
http://www.marmoset..../pbr-conversion

http://artisaverb.info/PBT.html

[Mblackwell]

From memory:
Alpha is the exponent/power of the specular highlight (or gloss/reflectivity). A simple greyscale image in the RGB channel gets you Doom 3 level of specular, and then playing with the alpha channel lets you get fancy.

[Tea Monster]

Trooper Dan, on 10 June 2016 - 12:48 PM, said:

Changed the thread name. Got tired of seeig "death of Polymer" when I'm still using it and it's getting fixed now.

If you were using it the way we are, you wouldn't have changed the title.

Even with Hendrix's efforts to fix things, we are spending one day building a prop and three days debugging problems with spec and normal maps causing shading errors on props. It looks like the bug I described to Plagman in our original report has returned. Objects have different amount of specularity depending on what angle you view it at. It looks like polished glass on one side. Walk around the object and suddenly it looks flat and washed out. Steeevie's hydrant exhibits this if you want to check it out in game.

Recently I enabled gloss maps on one of our barrier props. They glow like they were manufactured in Chernobyl. They are visible across the map like orange kryptonite. I'm going to disable them and wait till more pressing problems get sorted out before I delve into them again.

Mark and I are currently investigating what is causing the spec/normal problems so we can report it properly.

[Plagman]

Are the normals properly built for the model itself? What you describe sounds like they might all be facing the same way.

[Spiker]

Probably they were broken on export but using md3 compiler isn't a perfect solution either. FBX to the rescue.

[Mark]

Here is another real head scratcher of a problem. There is a large building face model placed on the front face of a plain square building sector. 4 Polymer point lights are placed in front of it to illuminate it a certain way. In Mapster the model is lighting up just fine. In the game, it does not get lit up. I tried placing the model in various places in the map, same issue. Just to play it safe I increased maxlightpasses to 8 in case there happen to be any more lights in the map affecting it somehow. Same issue. So I thought its just a matter of the model lighting up in Mapster but not in Eduke for some reason. But to my surprise, as I created a small test map to send out for a bug report, the damn model is lighting up in both Mapster and Eduke as it should in that test map.

How could this problem possibly be caused by the original map itself? AARRGG!!!!

[Danukem]

^^ Make sure there is no CON code which could be culling lights in the larger map.

[Mark]

We have been avoiding any new con code so far. Thanks.

[Mblackwell]

For the sake of curiosity delete a few lights and see what happens.

[Mark]

I'll give that a try but I have my doubts. I have added more lights around the map since this problem started and they are working.

EDIT: No difference after deleting 7 lights in the area. DUH, I failed to notice ( and mention ) that another model next to the unlit one does get lit by those 4 lights. So once again it appears to be model specific. But then why does it light up only in Mapster in this map or Mapster and Eduke in a test map?

[Hendricks266]

Send me an isolated test case that exhibits the issue.

[Mark]

It just got even weirder. Just to verify the 4 lights are shining fully and properly I raised the model in question up about 20 pgup clicks to reveal the sector wall behind it. The wall is fully lit up as expected. But low and behold, the bottom section of the model was still within range of the lights and it was lit up. So now it becomes a question of why the hell is model height in the map dtermining whether it gets light or not.

Hendricks: I can't. If that same model is placed in a bug test map it works fine in Mapster and Eduke. Its only a problem in its original map. Plus I placed this model elsewhere in it's original map and it was still unlit.

[Kyanos]

First, if it's a new piece I would define it to a new tile (might be some hardcoded issue) then I'd try to import/export cycle the model through blender maybe it's something odd in the model itself?

Or maybe it's something silly like two sprites (the model) existing in the same spot, or the sprite as the engine sees it is in void space somehow culling itself from the light pass (like it might go into the sky)

A final thought, try to copy paste the offending part of the map to a new map and see if once isolated it works exactly as you have it now.


final final thought, is the sprite wall aligned and z fighting?

[Kyanos]

Mark., on 19 June 2016 - 12:00 PM, said:

It just got even weirder. Just to verify the 4 lights are shining fully and properly I raised the model in question up about 20 pgup clicks to reveal the sector wall behind it. The wall is fully lit up as expected. But low and behold, the bottom section of the model was still within range of the lights and it was lit up. So now it becomes a question of why the hell is model height in the map dtermining whether it gets light or not.

Hendricks: I can't. If that same model is placed in a bug test map it works fine in Mapster and Eduke. Its only a problem in its original map. Plus I placed this model elsewhere in it's original map and it was still unlit.

Quote

or the sprite as the engine sees it is in void space somehow culling itself from the light pass (like it might go into the sky)

After that last post of yours I'll vote this.^^

Try to break the model up into smaller pieces to fit the space in the sector better, or put the model below the origin so the sprite lifts up some to keep the mesh where you want it while the game sees the sprite better for the light (if that makes sense)

edit; you can turn models off and you can check to see that black square from running dummytile for the sprite is within sector bounds. (maybe you could define a larger tile to fix this issue??)

third or fourth edit; I'm positive the dummytile code is set here for something generic like 32 x 32 and the lights are just missing the sprite itself, so the model is not catching lights, make the sprite coded to be the same size as the model. (no matter how much you use models the engine will always be sprites at the core)

[Mark]

The model was run through 3 different programs and looks to be proper. It is already in a new custom tile number so shouldn't be conflicting with any hard coding. There isn't any other sprite behind to z fight with.

[Mark]

If thats the case, why does it light up properly in Mapster? Plus it doesn't work when placed elsewhere in that map. Its a tough nut to crack.

I'm going back into the map to see where exactly heightwise the model started to get lit. Its going to be tedious trial and error but what else is there?

I think every dev should be required to download every work in progress project so they can jump right in and help when needed. Just kidding. I'm trying to keep from crying in frustration. This project has been cursed with these kinds of issues for a while now.

[Mblackwell]

It's outside, I imagine?

Is the ceiling high enough in that area?