Polymer lives again
#181 Posted 10 July 2016 - 04:36 PM
On a related note, has there ever been any ideas for when invalid geometry is encountered how Polymer should respond in terms of trying to stitch these holes shut rather than leaving them as-is?
#182 Posted 16 July 2016 - 01:18 PM
Or try to find the original map on disk or just store into the save to pull it from that.
#184 Posted 24 October 2016 - 06:07 PM
Drek, on 28 May 2016 - 01:54 PM, said:
OK, it's a mapster thing, renders shade lines and skies weird, starting rev 5001, good at 4980.
4980;
5001;
^doesn't look so bad in the pic, but it's horrid to look at in real time while moving the camera.
(not a bug report, I'm fine mapping in an older version on this old laptop. I only posted in the small hope my issue helps track down the others)
Which renderer is this?
#185 Posted 25 October 2016 - 04:28 AM
This post has been edited by Drek: 25 October 2016 - 04:30 AM
#186 Posted 10 January 2017 - 06:24 AM
Any progress on getting the render issues sorted out?
This:
And the Alpha issues.
This post has been edited by Tea Monster: 10 January 2017 - 06:24 AM
#188 Posted 10 January 2017 - 06:54 AM
#189 Posted 10 January 2017 - 11:28 AM
Tea Monster, on 10 January 2017 - 06:24 AM, said:
Any progress on getting the render issues sorted out?
This:
And the Alpha issues.
I narrowed this down to r4600 but have not had a chance to investigate further.
#191 Posted 06 April 2017 - 03:29 PM
#192 Posted 06 April 2017 - 05:26 PM
Tea Monster, on 06 April 2017 - 03:29 PM, said:
This will be far more likely to be looked into if you could provide what's needed to replicate the problem (the map, models and defs). From your description, it sounds like specular and gloss highlights are working correctly on the problem models when in other sectors. That makes me wonder if it's a lighting priority issue. EDIT: Have you checked to see whether the problem is sensitive to the max number of lit surfaces setting?
This post has been edited by Trooper Dan: 06 April 2017 - 05:42 PM
#193 Posted 06 April 2017 - 06:16 PM
This post has been edited by HellFire: 06 April 2017 - 08:17 PM
#194 Posted 06 April 2017 - 06:26 PM
#195 Posted 06 April 2017 - 11:56 PM
Trooper Dan, on 06 April 2017 - 05:26 PM, said:
I'm loath to go through all that documentation of a problem again. For the normal and diffuse display issues, both myself and Mark spent a lot of time documenting the problem. Levels, defs and models were submitted and Mark went through every version of EDuke between the one we are using now and the latest SVN to determine where the problem first occured. After all that effort on everyone's part, nothing has been done to actually fix the problem. I personally don't want to go through the procedure again to come up with the same result. I'm wasting my time and the devs if nobody is going to do anything about it.
Re: NG: - As Mark said, ICD says it isn't dead, but for the purposes of this mod and EDuke in general, I am considering it deceased.
Re: LIghting limit - No I haven't, can you point me to the wiki page please?
#196 Posted 07 April 2017 - 12:59 AM
Tea Monster, on 06 April 2017 - 11:56 PM, said:
http://wiki.eduke32....onsole_commands
r_pr_maxlightpasses
"the maximal amount of lights a single object can by affected by"
The default value is 5. But you can open up the console and change it to a different number. For example, by typing:
r_pr_maxlightpasses 9
In the unlikely event that this helps, you can save that setting in a cfg or have it applied at startup in an autoexec.cfg
#197 Posted 07 April 2017 - 03:22 AM
#198 Posted 07 April 2017 - 03:48 AM
Mark., on 06 April 2017 - 06:26 PM, said:
It had a planned release date?
It's possible ICD may being working on it again in 6 months or so, but feelings will be spared if it were simply assumed to never happen, and be pleasantly surprised if it does.
#199 Posted 07 April 2017 - 04:08 AM
#200 Posted 07 April 2017 - 11:50 AM
#201 Posted 28 July 2017 - 01:54 PM
Tea Monster, on 10 January 2017 - 06:24 AM, said:
Any progress on getting the render issues sorted out?
This:
This is now fixed.
#203 Posted 28 July 2017 - 02:09 PM
#204 Posted 28 July 2017 - 02:44 PM
icecoldduke, on 28 July 2017 - 02:09 PM, said:
In any case, you should be able to answer your question merely by looking at our SVN.
http://svn.eduke32.c...v=6396&peg=6396
This post has been edited by Hendricks266: 28 July 2017 - 08:57 PM
#205 Posted 12 August 2017 - 10:27 PM
#206 Posted 13 August 2017 - 08:36 PM
#207 Posted 13 August 2017 - 09:06 PM
Mark., on 13 August 2017 - 08:36 PM, said:
True, I'm sure it would need a lot of additional development but you know, that's what NG would have meant anyway. On top of that it would be really worth it in my opinion, I mean WT = Duke 3D running on DirectX 11. That's great new tech that would open doors to a lot of opportunities even just as an example on how to move forward in certain directions. I can say a lot of bad things about how I think GBX handled WT badly but it's still the most significat official source port any classic FPS got maybe ever.
This post has been edited by Zaxx: 13 August 2017 - 09:09 PM
#208 Posted 14 August 2017 - 12:49 AM
Zaxx, on 12 August 2017 - 10:27 PM, said:
Well, I gotta admit, the WT renderer does look really nice. Besides we really need the WT source code to properly implement the new changes (incinerator, firefly, ...) into EDuke32. And the fact that WT is now officially the latest and final version of Duke Nukem 3D.
Any news on its release by the way? According to the interview, Randy promised to look into it to see if it was possible.
This post has been edited by axl: 14 August 2017 - 12:56 AM
#209 Posted 14 August 2017 - 01:10 PM
I'm sure that any performance increases are from the renderer having some form of multithreading and batched calls. Something that should be targeted for all the current GL renderers in EDuke32 at some point.
#210 Posted 15 August 2017 - 12:36 AM
Mblackwell, on 14 August 2017 - 01:10 PM, said:
I'm sure that any performance increases are from the renderer having some form of multithreading and batched calls. Something that should be targeted for all the current GL renderers in EDuke32 at some point.
Guess performance depends on what hardware you throw at the game but compared to Polymer WT will perform 5 to 10 times better in any given situation on adequate hardware.
Here's how performance goes basically: Polymost > WT classic mode >= WT true 3D rendering > EDuke32 Classic renderer >>>> Polymer. As for frame pacing I've yet to measure it but when it comes to the general feel of smoothness World Tour wins hands down. Screen tearing is handled a lot better and the game feels a lot smoother even on a lower framerate as is the case with most DirectX 11 games.
And yeah, DirectX throws multiplatform support out the window but it would still benefit Windows users a lot. What I also like in Gearbox's renderer is that it supports DSR and Fast Sync and those things are missing from EDuke32 (fast sync works but only through the classic renderer and on my machine it's basically useless in 1080p because framerate dips below 120 fps a lot resulting in a very stuttery experience).