[HiPolyBash]

MusicallyInspired, on 26 May 2016 - 08:04 PM, said:

Then again, I haven't run into anything audio-wise that I'd ever want to change so drastically.

...I kinda want multichannel support...

[MusicallyInspired]

Ok, music-wise.

[HiPolyBash]

I'd really like your SC-55 music packs to be bundled by default because they're fuckin' awesome

[Kyanos]

with polymost geo rendering you shouldn't have to fix any of the known polymer deficiencies discussed earlier, like drawing walls above and behind parallaxed ceilings.

It seems like this could be a hybrid of the best parts of both old renderers, good luck.

[TerminX]

One of the primary reasons Ken even wrote Polymost was that nobody else had done a proper hardware accelerated renderer, as everyone was too stuck in the mindsets that lead them to believe stuff like Build's portals and fully dynamic map structures were incompatible with 3D rendering or impossible to get working properly. It's an unconventional engine with unconventional principles, but supporting it all is fully possible if you look at it from the right perspective.

[MusicallyInspired]

HiPolyBash, on 26 May 2016 - 08:14 PM, said:

I'd really like your SC-55 music packs to be bundled by default because they're fuckin' awesome

It does with Megaton (or rather, did ).

[Mblackwell]

We love you even without Megaton pimping your wares.

[TerminX]

You guys should have heard the version of Grabbag I had him do for HTTKC.

[Trebor_UK]

HiPolyBash, on 26 May 2016 - 08:08 PM, said:

...I kinda want multichannel support...

HDR audio, like Frostbite engine

[Danukem]

So, it seems that icecoldduke became the last person on the forum to discover that Polymost runs a lot faster than Polymer, and is now excited about leveraging Ken's code. This made me wonder about why Plagman didn't do the same thing when developing Polymer in the first place. I thought he must have had a good technical reason. I did some forum searches and wasn't able to turn up anything on that subject. One thing I did find was this:

https://picasaweb.go.../PolymerHistory

It's an album with commentary that Plagman made, showing progress on Polymer, starting in 2006. One thing I gathered from his commentary is that it was a learning experience. I don't think he even considered basing his work on Ken's because he wanted to make a renderer of his own.

[Mark]

Hendricks266, on 26 May 2016 - 07:25 PM, said:

To anyone emailing icecoldduke: post here for all to see instead of going behind the EDuke32 team's backs.

Attached thumbnail(s)

• 

[icecoldduke]

TerminX, on 26 May 2016 - 09:20 PM, said:

One of the primary reasons Ken even wrote Polymost was that nobody else had done a proper hardware accelerated renderer, as everyone was too stuck in the mindsets that lead them to believe stuff like Build's portals and fully dynamic map structures were incompatible with 3D rendering or impossible to get working properly. It's an unconventional engine with unconventional principles, but supporting it all is fully possible if you look at it from the right perspective.

Very true .

[Micky C]

I feel like I missed something. So PolymerNG will be fast for all maps now? (Perhaps even faster than originally thought possible?)

[Kyanos]

Quote

Half a year later, still experimenting with various hidden surface removal techniques. This illustrates a visportal-based method. Very efficient when you have a couple of portals in view, but absolutely not suited for rendering a thousand sectors at the same time.

from the polymer history page DT linked to.
https://picasaweb.go...445880911346834

Micky C, on 27 May 2016 - 03:53 AM, said:

I feel like I missed something. So PolymerNG will be fast for all maps now? (Perhaps even faster than originally thought possible?)

basically, icecoldduke is putting the polymost geometry rendering/culling into play instead of the visportal style from polymer.

[icecoldduke]

Drek, on 27 May 2016 - 04:10 AM, said:

basically, icecoldduke is putting the polymost geometry rendering/culling into play instead of the visportal style from polymer.

Correct. I'm going to ditch a lot of code, and refactor a bunch of code to get Polymost in but its the correct solution to the problem.

If anyone has a second, who has low end PC, load up Clear the Coast and tell me what your framerate is through out the map.

[Paul B]

I think what they are alluding to is PolymostNG. But polymost doesnt handle TROR. Unless there is a plan to make that happen ?

[Kyanos]

icecoldduke, on 27 May 2016 - 04:18 AM, said:

If anyone has a second, who has low end PC, load up Clear the Coast and tell me what your framerate is through out the map.

Didn't play it all again, but that first shot down the canyon (from on top of the blue teddy bear) never dropped below 150fps 6-7ms

core2duo 3Ghz
gt640 2gddr3

[icecoldduke]

Paul B, on 27 May 2016 - 04:18 AM, said:

I think what they are alluding to is polymostng. But polymost doesnt handle TROR. Unless there is a plan to make that happen ?

Yeah that one is a problem, and I have heard nasty things about TROR and Polymost. I probably don't have the bandwidth to fix it. There are trade off's guys, I can't fix everything .

[Paul B]

In my opinion this is a huge step backwards. Why fix something that isnt broken? The only decent feature that came out of the engine since 1996 was TROR. I hope there is a method to fix this? For me this would be taking a 2016 engine and back dating it to 1996 and for what purpose? Only to appease maps that were bundled in DukeZone and an audience which is no longer around since all those old mappers have moved on. Is this about supporting a dinosaur or moving forward with the times?

[Kyanos]

The dev team mentioned getting polymost and TROR working together for the Bombshell preview, apparently it's possible.

Hendricks266, on 26 May 2016 - 07:34 AM, said:

We've talked with Helix a little bit more about it due to the Bombshell prequel. It is doable with proper effort, but it would be an undertaking.

Paul B, on 27 May 2016 - 04:31 AM, said:

In my opinion this is a huge step backwards. Why fix something that isnt broken? The only decent feature that came out of the engine since 1996 was TROR. I hope there is a method to fix this? For me this would be taking a 2016 engine and back dating it to 1996 and for what purpose?

IMO TROR can get figured out after the original game and normal user maps run at speed.

[icecoldduke]

Paul B, on 27 May 2016 - 04:31 AM, said:

In my opinion this is a huge step backwards. Why fix something that isnt broken? The only decent feature that came out of the engine since 1996 was TROR. I hope there is a method to fix this? For me this would be taking a 2016 engine and back dating it to 1996 and for what purpose?

I can't fix everything, using Polymost logic to render geometry is the correct solution.

Drek, on 27 May 2016 - 04:36 AM, said:

The dev team mentioned getting polymost and TROR working together for the Bombshell preview, apparently it's possible.

Hendricks266, on 26 May 2016 - 07:34 AM, said:

We've talked with Helix a little bit more about it due to the Bombshell prequel. It is doable with proper effort, but it would be an undertaking.

I have no doubt it possible, but I don't have the bandwidth for it. Judging by this comment, doesn't look like TROR is currently working Bombshell?

[TON]

Plagman, on 29 March 2014 - 02:44 PM, said:

The only problem with the current tessellation approach is that with forward rendering, triangles are rendered once per light that affects them. Sectors can create triangles with extremely large areas, which will end up rendered fully for every small light that touches them. That is why breaking down big sectors in smaller sectors is sometimes a performance win, as fill rate can become an issue. One optimization that would help with the current scheme would be to project the light volume onto the screen before doing a light pass, and set a scissor rectangle to the boundaries of that area before rendering the affected geometry. The real fix would be to move to a deferred approach.

icecoldduke said:

What needs to be done:
Get deffered lighting system in.

PolymerNG could win more fps using your deferred lighting system compared with old method in Polymer
How many fps? 10fps?

[icecoldduke]

TON, on 27 May 2016 - 05:07 AM, said:

PolymerNG could win more fps using your deferred lighting system compared with old method in Polymer
How many fps? 10fps?

Polymer's forward lighting was not the only problem with the renderer, when it came to performance. The vis portal system in Polymer was using occlusion queries between sector draw calls, which caused sync points on the GPU. This was a big issue. That mixed with bunches of small draw calls, caused performance issues.

This being said, Polymost has its own draw backs. You have to submit the vertexes for the entire level, every frame :/. I hate this on principle but it seems to yield good performance. In Polymost, Ken also submits a bunch of small draw calls, while sending vertexes to the GPU every frame. I plan on building the entire vertex buffer list, and submit it all at once, then issuing the render call. This should make PolymerNG "Polymost" implementation faster then the original Polymost.

[Micky C]

Damn, really no way to get the flawless TROR of polymer into the new renderer?

[Paul B]

Micky C, on 27 May 2016 - 05:17 AM, said:

Damn, really no way to get the flawless TROR of polymer into the new renderer?

I know I thought he was my friend! LOL! Anyway, if Helix would come back and contribute to make this work then we may just end up with the best of both worlds. Also Terminx made mention that he might be able to hack TROR into Polymost. So i'm going to sit tight and not let this wedgie bother me.... for now. Like Terminx said: " It would be a BIG FAIL to not account for TROR" with a new renderer.

[icecoldduke]

Paul B, on 27 May 2016 - 05:24 AM, said:

I know I thought he was my friend! LOL! Anyway, if Helix would come back and contribute to make this work then we may just end up with the best of both worlds. Also Terminx made mention that he might be able to hack TROR into Polymost. So i'm going to sit tight and not let this wedgie bother me.... for now. Like Terminx said: " It would be a BIG FAIL to not account for TROR" with a new renderer.

While true, time to go grab Helixhound and make him fix it .

[Kyanos]

Paul B, on 27 May 2016 - 05:24 AM, said:

I know I thought he was my friend! LOL! Anyway, if Helix would come back and contribute to make this work then we may just end up with the best of both worlds. Also Terminx made mention that he might be able to hack TROR into Polymost. So i'm going to sit tight and not let this wedgie bother me.... for now. Like Terminx said: " It would be a BIG FAIL to not account for TROR" with a new renderer.

what released works make use of TROR? what exactly would we miss out on?

side note; going the polymost way will make the new renderer more compatible with WGR2, DNF2013 & Imperium TC (multiple skies, level geometry seen through skies, horrid framerates...)

[icecoldduke]

I plan on using the perspective correct sprite code that I'm already using(based on whats in Polymer); I remember some issues were with Polymost with sprites when you look up at them, or something like that. A) is that still valid fuckage in Polymost? B ) does anyone have a problem with me doing that.

[MusicallyInspired]

You mean so that sprites never get skewed on an angle? I always disliked that about true 3D source implementations of 2.5D games.

[Danukem]

Micky C, on 27 May 2016 - 05:17 AM, said:

Damn, really no way to get the flawless TROR of polymer into the new renderer?

It's way too early to make that assumption. Time will tell, but it seems that icecoldduke is on the right path this time. It would suck to lose (glitchless) TROR, but remember Polymer would still exist and TROR wasn't working in Polymost anyway. It's a relatively recent feature; it makes infinitely more sense to compromise TROR than to compromise SOS. Keep in mind we also get multiple skies and anything else that was already working in Polymost but not Polymer. It's a big win, assuming he can pull it off.