[Tea Monster]

Something is definitely weird in how models are rendered in Polymer. Models appear correctly lit back in ver. 4593. In more recent versions (Can't remember the version No. But in August of this year), Models look very dark. This is not a model issue as the same models appear completely different in the two versions of the renderer.


Same model, same level, same lighting, different SVN version.

[Micky C]

That was the new feature introduced in 4596; the ethnic diversity shader.

[Tea Monster]

Diversity through programming, the wonders of modern technology!

[Mblackwell]

 Tea Monster, on 04 September 2016 - 01:24 AM, said:

Something is definitely weird in how models are rendered in Polymer. Models appear correctly lit back in ver. 4593. In more recent versions (Can't remember the version No. But in August of this year), Models look very dark. This is not a model issue as the same models appear completely different in the two versions of the renderer.


Same model, same level, same lighting, different SVN version.

Er... can you narrow it down more?

There's there's about a thousand revisions since that one.

[Mark]

IIRC its gone back and forth a couple of times during that span. I've lost track of the various revisions brought up each time this has been a problem during that span.Sometimes a tweak was made and a revision worked better but still not quite right. I think his point was that its not a model problem which was a possibility during some of those discussions. I'm pretty sure TM has been in PMs with a couple of the devs descibing details.

From what I can gather, as soon as normal maps are applied ( with any settings ) the diff map refuses to illuminate from light sources.

[Mblackwell]

But if you can narrow it down to the first bad commit then they can work out the root of the problem.

Edit: You said 4593 was good. Try 4600 (for example).

[Mark]

Thats all "been there and done that" a few times already. The problem is elusive and we have people busy with other things and real life so a complete solution hasn't appeared. The people with the best chance of fixing it have the info from past posts and PMs on the subject.

The first bad commit was whatever came after 4593. And since then there have been a few attempts of fixes that were partially successful and then later on after another update it seemed broken again.

So other than 4593 and the next revision, there is not a clear cut case of "this version worked perfect and this one doesn't". There isn't an easy comparison to make for tracking purposes.

[Mblackwell]

The best chance really is to find the first bad commit.

If you send me a test setup I can bissect it.

[Mark]

4593 was the last working public revision. Start from there.

After 4593 there were a series of many dozens of uncommited revisions before the next public release. I went through this with Hendricks and we had it narrowed down to about a dozen or so IIRC. But then it got dropped for whatever reasons. I no longer remember the range he was checking last time. It was a long time ago.

[Tea Monster]

Mark narrowed down where the problem started, which version it was and all this has been forwarded to both TX and Plagman. We've been talking to them about this for a while now.

[Mblackwell]

 Mark., on 04 September 2016 - 02:58 PM, said:

4593 was the last working public revision. Start from there.

After 4593 there were a series of many dozens of uncommited revisions before the next public release. I went through this with Hendricks and we had it narrowed down to about a dozen or so IIRC. But then it got dropped for whatever reasons. I no longer remember the range he was checking last time. It was a long time ago.

That's why I suggested r4600. It's the first revision with explicit changes to Polymer. If you send me a test case I can verify it and bug people about it.

[Hendricks266]

Can you forward the email chain to me or add me to that PM (or bump it if I already am)?

[Mark]

Tm should have that info.

I looked back through my PMs and there were multiple conversations spread out over time. One of them was concerning a framerate drop. It also by coincidence revolved around 4593 being the last good one.

Thats the one you and I were bisecting the crap out of.

[Jmoc]

I don't know if this is the right place to say that, but did you have a look at the "new" Duke Nukem 3D 20th anniversary?


Those lights reminds me of Polymer....

[Player Lin]

I guess everyones on Duke4.net should already know the weird textures with extra maps shit World Tour trailer.

[Tea Monster]

Yeah, and it isn't actually Polymer and has SFA to do with this thread.

[Jblade]

Any check of a userdef or something similar so we can detect if the player's using widescreen mode? Using it messes up the angle of skyboxes (I don't know enough about what widescreen actually changes beyond the immediate visual appearence of everything being 2x as tall so I can't really explain the issue well enough) so I need to figure out a way of making it work in both modes.

[Hendricks266]

xdim and ydim are available in CON, but are you asking for read access to r_usenewaspect?

Maybe your skybox problem is an oversight in the source. Could you show screenshots?

[Tea Monster]

Any progress on the dark rendering or the transparency problems?

[Jblade]

Hendricks266, on 12 September 2016 - 03:17 AM, said:

xdim and ydim are available in CON, but are you asking for read access to r_usenewaspect?

Maybe your skybox problem is an oversight in the source. Could you show screenshots?

Sure - here's two pics of widescreen on and off showing the problem. When widescreen is off the skybox matches the player's horiz perfectly, but turned on it doesn't seem to take on the same horiz value or whatever. The purple building shows this in effect.

Attached thumbnail(s)

• 
• 

[Apiai]

Hi,

I don't understand why sometimes I see some 3D models (pigcops gibs and ejected ammos) in classic mode (eduke r5811 + Dukeplus 2.40)

How is it possible ?

[Danukem]

Apiai, on 12 September 2016 - 10:57 AM, said:

Hi,

I don't understand why sometimes I see some 3D models (pigcops gibs and ejected ammos) in classic mode (eduke r5811 + Dukeplus 2.40)

How is it possible ?

That's Dukeplus, it's not EDuke32's fault. Pigcop jibs do not exist in sprite form, so you will still see models for those even without the HRP (by the way, you can't really mean classic, because there is no way that the classic 8-bit renderer is rendering models). You will also see some other models such as the shell casings and some of the new guns. If you go through the Dukeplus menu you can turn some of that stuff off.

[Jblade]

Projectiles that are set to explode after bouncing a certain number of turns no longer explode now - they just bounce around until they stop and then bounce on the spot indefinitely.

[Mblackwell]

turn off explodeontimer 16384

alternatively make sure both 16384 and 64 (timed) are set and define range.

This was broken before.

[Danukem]

Mblackwell, on 15 September 2016 - 09:07 AM, said:

turn off explodeontimer 16384

alternatively make sure both 16384 and 64 (timed) are set and define range.

This was broken before.

Just to be clear: what exactly was broken? Projectiles that explode after a certain number of bounces have worked for as long as I can remember.

[Hendricks266]

 Mblackwell, on 15 September 2016 - 09:07 AM, said:

This was broken before.

"Bouncing in one spot" sounds pretty broken in its own right.

[Mblackwell]

 Trooper Dan, on 15 September 2016 - 10:18 AM, said:

Just to be clear: what exactly was broken? Projectiles that explode after a certain number of bounces have worked for as long as I can remember.

Timed projectiles.

[Mblackwell]

 Hendricks266, on 15 September 2016 - 03:39 PM, said:

"Bouncing in one spot" sounds pretty broken in its own right.

If you have 16384 (EXPLODEONTIMER) set but not 64 (TIMED) set then the game doesn't read RANGE as the TIMER so it can't figure out when it should explode.

[Danukem]

 Mblackwell, on 15 September 2016 - 09:19 PM, said:

If you have 16384 (EXPLODEONTIMER) set but not 64 (TIMED) set then the game doesn't read RANGE as the TIMER so it can't figure out when it should explode.

Got it. I'm pretty sure that I have always had both of those set on my timed projectiles because the documentation said to do so.

By the way, what would be the use case for having one flag set but not the other?

[Jblade]

I don't know what the conclusion here is but the projectile in question isn't set to explode on any kind of timer, they're supposed to just bounce 6 times or whatever and then explode at the end. This isn't working anymore.