[TerminX]

MusicallyInspired, on 27 May 2016 - 07:43 AM, said:

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

I don't think that's really possible. I mean, it's possible in terms of yes, you can program it to do that, but you end up with issues. There's a cvar in Polymer that does that--try it out and watch things like toilets clip into walls when you look down at them.

[MusicallyInspired]

Just consequences of true 3D space I guess then.

[icecoldduke]

Instead of switching the entire renderer over to Polymost, I instead used Polymost for doing occlusion culling, and rendering the same way as before. You get SOS now and all the fun features you get in build, while WAY faster then the previous fast vis pass. I have not tested TROR yet.

High end PC.
CPU: 5ms
GPU: Less then 1 millisecond



I haven't tried this on the xbox one yet.

I think I can get the CPU also under 1ms or close to that by porting Polymost over to SSE.

[Kyanos]

icecoldduke, on 27 May 2016 - 12:49 PM, said:

I think I can get the CPU also under 1ms or close to that by porting Polymost over to SSE.

this? https://en.wikipedia...SIMD_Extensions

Also amazing to see that working so fast!

To test TROR play trueror1.map in the samples folder. Go behind the start point, just up the stairs and look all around the ceiling in that room.

I get this mess in Polymost.

[icecoldduke]

That will probably work because I'm not using Polymost for rendering, only for figuring out what's visible.

[Kyanos]

 icecoldduke, on 27 May 2016 - 01:19 PM, said:

That will probably work because I'm not using Polymost for rendering, only for figuring out what's visible.

It would probably take you just as long to go check as it did to write that post

Tell us it's fast with SOS and TROR working

[icecoldduke]

 Drek, on 27 May 2016 - 01:24 PM, said:

It would probably take you just as long to go check as it did to write that post

Tell us it's fast with SOS and TROR working

This is how fast it is with SOS . TROR is still untested, I'll test that soon. I'm doing other things atm.

TROR is broken, I'll add it to my todo list, but SOS works fine.

[icecoldduke]

Here is a new video of clear the coast running at 20ms(~40fps) on the the xbox one, which is the min spec for PolymerNG. This again uses Polymost for occlusion detection only. I'm uploading a E1L1 play through to that SOS works fine. To be clear in both videos HRP high res palettes are broken. So you will see a red ocean in this video and in the next one you'll see white walls in the movie theater. This will be fixed, just focus on how well things are running .

[icecoldduke]

E1L1 walk through to show SOS works. Yes some ground sprites are missing, I have the HRP installed and I was in the middle of getting that working, when the occlusion discussion started happening. So you will see missing sprites, thats because its currently looking for a model that doesn't have support yet. When you see the white theater walls its because I don't have high quality palette support yet.
Just focus on SOS is working with PolymerNG, and everything is running at 1ms on the damn xbox , that is 4x faster then the fast pass that didn't support SOS .

**EDIT** hit wrong button on youtube and deleted it on accident, will update when its back up.

[Hank]

I'm lost.

Assume a mapper wants to make new maps. Completion date, 3. Dec. 2016, or later, say Jan. 2017

Can he plan for high definition textures?
Can he use TROR?
Can he plan for static obj type models?
Can he plan for Collada (or FBX) actors with skeletons?
OR shall he stick with the status quo for now and use mapster32, plain with sprites?

[Kyanos]

icecoldduke said:

Polymost for doing occlusion culling

I took a top down screenshot in mapster for readers to reference. The player is in the bottom right of the highlighted area. The highlighted area is what the renderer sees (in the fulstrum) then needs to decide what to draw (math-algorithm) it's over 1000 walls and 400 sectors in this case.

[icecoldduke]

 Hank, on 27 May 2016 - 03:43 PM, said:

I'm lost.

Assume a mapper wants to make new maps. Completion date, 3. Dec. 2016, or later, say Jan. 2017

Can he plan for high definition textures?
Can he use TROR?
Can he plan for static obj type models?
Can he plan for Collada (or FBX) actors with skeletons?
OR shall he stick with the status quo for now and use mapster32, plain with sprites?

Yes
Unknown
Yes
Yes
Which ever you prefer.

[Kyanos]

 Hank, on 27 May 2016 - 03:43 PM, said:

I'm lost.
Assume a mapper wants to make new maps. Completion date, 3. Dec. 2016, or later, say Jan. 2017

I learned this one working on WGR2.
DO NOT MAKE PLANS TO USE ANY UNFINISHED PRODUCT.

[icecoldduke]

E1L1 using Polymost for occlusion, on the XB1. Any visual bugs are caused by models only being half hooked up at the moment. Also doesn't help that HQ palettes aren't hooked up yet either. It only takes 1ms to render on the XB1.

[Mblackwell]

What's with the occasional flicker when entering a new area?

[icecoldduke]

 Mblackwell, on 27 May 2016 - 04:59 PM, said:

What's with the occasional flicker when entering a new area?

Not sure, that's been in there for awhile, I'm not sure what it is off hand.

 Drek, on 27 May 2016 - 03:47 PM, said:

I took a top down screenshot in mapster for readers to reference. The player is in the bottom right of the highlighted area. The highlighted area is what the renderer sees (in the fulstrum) then needs to decide what to draw (math-algorithm) it's over 1000 walls and 400 sectors in this case.

Thats actually a very informative screengrab, thanks . Aside from that I look forward to you guys stress testing the shit out of PolymerNG.

[TerminX]

I'm impressed (and happy) with the leveraging of Polymost to perform occlusion culling in software.

[Micky C]

 Drek, on 27 May 2016 - 07:27 AM, said:

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...)

The AMC TC makes extensive use of it which pretty much forces you to use the classic renderer, especially from Episode 2 onwards. Sure you could *almost* get away with polymost in some maps, but others are 100% unplayable.
Sure the TC could continue to use the classic renderer, but it'd be nice to have a few extra fancy effects in a NG renderer for those who want them. Plus it sounds like there'll be a big framerate boost over classic which will help a lot. (Don't worry icecoldduke we'll still design maps around classic so as to not take excessive advantage of polymerNG's framerate).

I'm under the impression that TROR is broken for different reasons in polymerNG than in polymost. If so, does that mean (and I'm aware you haven't looked into it much at this point yet so you can't give a solid answer) that it might not be the same massive undertaking it get it working?

[icecoldduke]

I have no more information to give on TROR yet. I dont want to guess and give out bad information. Ill let everyone know when i find something substancial.

[Plagman]

 Trooper Dan, on 27 May 2016 - 01:11 AM, said:

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.

I actually had started with Polymost as a base. There were not just one, but several technical reasons that made me reconsider and start over instead. Whether they were good or not is pretty subjective, but I can try to remember what some of the reasoning was at the time:

- We had several maps that had very poor performance in Polymost. I think they were maps with not necessarily huge open spaces, but tons and tons of tiny sectors visible at the same time used for map detail. I didn't want to start with an inherent bottleneck; it's not clear whether any of the iterations of Polymer were ever faster than these cases, (although they probably are with the new bucketing code) but that still seems like valid reasoning, even though the work to actually make it work was never done in a way that's useful to you guys.

- Polymost is awesome at being a BUILD renderer, but very inflexible. I wanted to work without inherent limitations, allowing things like tilted walls, ceiling/floor portals (what is now known as TROR), 6 degrees of freedom, etc. None of these things are possible with the very efficient, but also very targeted algorithm at the core of Polymost.

- Polymost is inflexible for other reasons; I realize it's not too helpful of an argument to a general audience, but the core code isn't easily extended, to put it mildly.

- I wanted to do things that required multiple passes from different viewpoints, like shadow maps. Polymost would have a CPU cost that scales up linearly with the amount of passes, whereas you can leverage the sector triangulation / GPU uploads of geometry that's common to several passes if you do it in a more static way.

I always operated under the assumption that every sector could change at any given point in time. All my iterations on the HSR algorithm were always trying to be provably correct and work in the most degenerate cases, which might have been part of the issue. Doing a Polymost or Classic pass on the CPU in a small buffer for HSR was always an obvious option, but I wasn't happy with it because I wanted to "crack" modern BUILD rendering and never have to chase little quirks and cornercases in obscure user maps. I was intentionally testing it on maps with hallways wrapping over each other, visible portions of larger overlapping sector simultaneously visible, etc. Again, walking folks through my reasoning, not trying to claim Polymer does it "better" because clearly it's full of shortcomings on various axes.

[icecoldduke]

 Plagman, on 27 May 2016 - 08:09 PM, said:

....

I completely agree with most of what you said. The reason I didn't use Polymost initially for PolymerNG was because the algorithm required each visible vertex to be resubmitted every frame. When Mblackwell pointed out the performance in Polymost, was actually higher then I expected...I realized I made a critical error, and used Polymost for occlusion culling on the CPU. I always believe in maximizing all hardware that's available to you. I know occlusion culling on the CPU(aka Umbra) vs doing it on the GPU is a very contentious topic. The fact is you usually have more CPU bandwidth to spare then GPU bandwidth. This is especially true in build, were you have a bunch of idle cores not doing anything.

The issue with build in general, the geometry generation pass makes a whole bunch of small pieces of geo, as your aware. What I would like to do is:

• Add virtual texturing
  
• A texture that contains each sector info(visiblility, shade, etc)
  
• A dynamic index buffer would get updated each frame with each triangle index that's visible for the current frame

This would allow me to send down everything in one draw call. At this point I believe the albedo pass would be as optimized as it can get; what do you think?

[HiPolyBash]

Is there any plan for a collaborative effort between the current EDuke32/Polymer team and what icecoldduke is doing with his PolymerNG renderer? I think it'd fragment the community if they continued in two different directions as two separate projects.

It seems as if efforts being consolidated into one big project would be beneficial to the community as a whole and it also looks like icecoldduke could use the assistance of someone familiar with the BUILD engine, Duke3D, and the Polymost/Polymer code base going forward considering the little bit of controversy that is stirred every time some issue comes up or it seems as if a compromise has to be made to keep performance up to expectations on the Xbox One before someone with more knowledge jumps in and points out something that would be obvious to the current EDuke32 guys.

[Danukem]

 HiPolyBash, on 28 May 2016 - 12:07 AM, said:

Is there any plan for a collaborative effort between the current EDuke32/Polymer team and what icecoldduke is doing with his PolymerNG renderer? I think it'd fragment the community if they continued in two different directions as two separate projects.

It seems like the threat of division has receded greatly since icecoldduke decided to use Polymost for occlusion culling. That eliminated the arguments about SOS, which was the most contentious issue to date. There will be plenty of other issues down the road, but I feel like that one was a turning point.

I don't think it's fair to say that icecoldduke and the EDuke32 team are going in different directions; for the most part, they are working on different things that are not in competition with each other. Polymer really hasn't been developed in a significant way for years.

[Hendricks266]

The projects will have to have an upstream/downstream relationship similar to Debian and Ubuntu for the forseeable future. A complete merge is desirable once PolymerNG meets the responsibilities of a source port, and can cleanly land on our codebase like the Enterprise-D saucer section.

[HiPolyBash]

Wouldn't it make more sense for PolymerNG to be available as an option in EDuke32 alongside Polymer/Polymost? It seems like it'd be easier, less divisive to the community as a whole and make more options available to content creators if everything were to be consolidated under the one banner as opposed to having a separate distribution for a version of EDuke32 that relied exclusively on the PolymerNG renderer with the exception of the UWP version for Xbox One.

I'm speaking much further into the future when/if it supports all the features that have been promised and much requested by members of the community. It seems extremely counter productive to limit the PolymerNG renderer to it's own separate EDuke32 distribution when it currently supports multiple renderers anyway.

[Danukem]

 HiPolyBash, on 28 May 2016 - 01:23 AM, said:

I'm speaking much further into the future when/if it supports all the features that have been promised and much requested by members of the community.

The funny thing is, you are actually proposing a stricter condition to be met than Hendricks266 did. He was just saying (in his typical non-diplomatic way) that the renderer has to meet the standards of the port before it can be merged. You are saying that it has to support everything that was promised and requested, which would go well beyond that Of course, he also implied that PolymerNG meeting those standards was not foreseeable, which I guess is technically true since we can't actually see the future...but that seems overly pessimistic.

[HiPolyBash]

I used that phrasing because it'd be pointless to make it available as an option if it did nothing better than what's currently available, I didn't mean to suggest that it had to support absolutely everything that had been suggested or stated in the past, just that it support the useful aspects of what had been discussed in the past and much of what has been requested by content creators for the last several years...because again it'd be absolutely pointless featuring it as an option in EDuke32 if it did nothing better or supported nothing more than what the current options do.

My point of view on things is that it'd be pointless to separate this renderer from EDuke32 as it's own distribution if it were to reach a state of functioning reasonably while supporting the more requested features from content creators, especially taking into consideration EDuke32 already has options for multiple different renderers. It'd be divisive, counter-productive in that content creators would obviously move toward the option that allowed them to go further while EDuke32 with Polymer were to still be worked on separately, and it'd severely limit options in the case of one renderer supporting a feature another did not, support for legacy content and content that takes advantage of features that may or may not be supported by PolymerNG such as true room over room, among other things..basically the more options the better. No point in relegating PolymerNG to it's own distribution of EDuke32 once it has reached a state of being fully functional with the features content creators have been requesting for years if it's going to limit the options available to the members of the Duke community.

[Danukem]

It's a non-issue right now because PolymerNG isn't even close to finished. Speculating about when would be the right time to merge it has the potential to cause an argument over nothing.

[icecoldduke]

 HiPolyBash, on 28 May 2016 - 12:07 AM, said:

Is there any plan for a collaborative effort between the current EDuke32/Polymer team and what icecoldduke is doing with his PolymerNG renderer? I think it'd fragment the community if they continued in two different directions as two separate projects.

My goal is to eventually get the code merged with main. You never merge code into main, much less changes of this magnitude, over to main until its passed rigorous quality control testing. You never merge unfinished code over to main. My intent is merging my code into eduke32 main, but that's not happening until:

• The product is finished.
  
• Meets the standards TX and Hendricks set.
  
• Has had rigorous testing done it.

I'm not trying to fracture the community. Even though it might seem like that's what's happening, this is how software development is done. You keep mainline working, while you work on fancy new tech and you don't merge fancy new tech with mainline, and break everyone, until at minimum those three conditions are met. It is the correct way to make software.

So I will continue to take changes from main into my branch. I will continue to post progress updates and code updates into my public branch. Then when things are nearing completion, you will know, because I will be asking for everyone to stress test the shit out of the code. Then after all of the bugs you guys find, get flushed out, then we talk about merging back to main.

[HiPolyBash]

Awesome to hear dude! I love following the updates to PolymerNG. I was unaware of what the overall end intention was and any replies given by Hendricks266 seemed to be ambiguous at best so many thanks for clearing that up.

What you're doing is awesome stuff. It opens up a world of opportunity to the Duke community when it comes to content creation lifting many of the constraints that have prevented people from working with EDuke32 and Polymer in its current state and will be exciting to see what comes of it.