[jimbob]

 Mark, on 13 October 2022 - 12:33 PM, said:

The original creator of the renderer left the modding scene before optimizing his code. From what I've heard, it is such a mess that people looking into finishing it have shook their heads and moved on.

they obviously never say any of my code

[Ninety-Six]

 Reaper_Man, on 13 October 2022 - 01:35 PM, said:

There's also this weird misconception that just because Build is an old engine, that means it should be able to do anything and do it fast and on any hardware.

That wasn't quite what I was getting at. I was referring to engines from near the same era, such as Quake(2) and GldSrc. Slightly newer than Build but not by much that ran on roughly the same hardware with this particular feature.

 Danukem, on 13 October 2022 - 12:40 PM, said:

It's hard to make dynamic lighting compatible with that and still run fast.

I suppose that's true. I guess that explains why in WT the point lights remain even if the attached light source is switched off (though GldSrc also added the ability to turn off and on some lights and it didn't seem to have that issue...?)

That said, didn't Quake 2 also feature dynamic lighting to an extent? The geometry still changed in that one, at least somewhat.

[Reaper_Man]

What I mean is that just because those engines were "just" 2 years newer and "ran on the same hardware" doesn't really matter as much as it may seem. The underlying technology is so vastly different to how Build (or even Doom) works that there's essentially no technological connection. Build in particular is such an outlier to basically every other game engine that you can't compare it to others. Then there's Unreal that had more dynamic lighting, but Unreal was built from the ground up independent of Quake/id engines. Quake-based engines with prebaked lighting did have some amount of "dynamic" lights (and fun fact, even Source 2 retains the same identical logic), but this was limited to static on/off lighting and it wasn't until much later this allowed for "moving" lights of any kind, or for geometry that moved to reflect lighting changes. This is why in Quake-based engines, even down through Source 1, moving geometry will retain the calculated lighting from its initial position. There are some tricks to hide this, but its still all precalculated.

[oasiz]

Wall of text....

Basis of 3D is models, split to triangles.
Take a room, split the geometry into triangles. That's step #1
Build/Doom/etc.. software rendering don't need to do this yet.

Quake is 3D, but it would be unreasonable to use a modelling tool to do this. Map editor is more of a tool to create "pseudo models" using building blocks that are more suited for 3D geometry.
This then gets chopped to a way more optimized 3D model (and triangles) through an automated compiling tool.
Specially tagged geometry bits (i.e. doors) are treated in isolation and gets flagged as an "entity", otherwise something like a closed door would have it's bottom/top removed as they couldn't be seen.
This is our basis for "dynamic vs. static" geometry in Quake as now we have objects that aren't welded to the main geometry. Think of them as "props / models", except done with the same editor.


Next you have the issue of rendering this 3D, what is visible and what is not. Also being able to determine what is in front/back.
3D can be extremely heavy if you don't have this data as even 3D accelerators had the role of drawing only and you had to use the CPU to build those calls.
Here is where the approaches diverge radically between conventional 3D and something like Build.

Long story short is that you can either approach this by pre-computing everything or working around this through other methods.
If you pre-compute, then you can dedicate hours on trying to find the right rendering order from given angles and camera positions.
This is what the BSP and VIS passes typically do in Quake/Doom.
With Doom there is only 2D to worry about so the complexity is vastly simpler compared to Quake where these computations can take hours to complete.
This exact same procedure is still required on Source2 maps.

The tradeoff? As everything is pre-computed, there are very limited or non-existing provisions to do this in real time. If you move a door for example then you're better off treating these as a simple "open" "closed" state and store these in the calculations. You can't have something like a huge vehicle, walk next to it as it moves and have it not render what's behind it even if it's taking all of your screen. In it's a reasonable trade-off however.
But imagine carefully calculating a boxy room and have an earthquake transform it's shape in real time. All of a sudden the square angles you have stored no longer apply, you might be able to swap between "start" and "end" states like a door but you can see that there is much less flexibility already. Storing every possible position the map can be in isn't really realistic.
This is why Doom/Quake/etc.. have a limited set of "known entities" like doors and platforms to make sure that any special optimizations are caught. It took until expansion packs to even get basic rotating objects and HL1 took this much further but still abiding by the same limitations.

And here is where the big difference comes.. Build has no concept of "entities".
Build doesn't do ANY precomputation for geometry, visibility, lights, etc.. It was built like this. It has a very clever way to accomplish, and It's fast too!
I won't go in to details how this is done but the end result is simply that the concept of "static" and "dynamic" never existed as there was no such "cheating" done, it cheated differently by the fact that the output didn't need to be true 3D.
This is why there is zero extra tax when it comes to wildly heavy changes between frames as it doesn't rely on any pre-computed data and can simply approach each frame "fresh".
Now we are getting to the root cause of the problem...
Build game you total freedom on how to handle geometry manipulation. Ken wrote some example "effects" that manipulate walls & sectors to create what we perceive as doors, elevators, etc.. Behaving much like entities.
Each one of these ran it's own bit of code, completely separate from the engine (game side).
What about the games? Well.. imagine 1994, you have 5+ developers who now want a "doom door" in their game. We're still on planet earth and just like any software development project, of course the result is that now we have 5 different incompatible implementations of the doomdoor, each one with it's own quirks, visual identity and tagging systems. Rinse and repeat this for any "effects" that a game might have and suddenly you find yourself comparing your 300+ "dynamic objects" against a handful from Quake (or even games like HL2). But that's just part of the problem.. Even with just accounting for one game, each "effect" is merely a macro against the geometry, this means that there is no real restriction on having multiple modifiers overlap (execute simultaneously, after each other, etc..), potentially giving very unpredictable results. Let's not even start with any effect extensions via modding.

Solid "dynamic" vs. "static" prediction is just near impossible to define reliably. Even Duke64 simplified some effects to get some extra shortcuts here (i.e. real moving subway doesn't exist)
This is why Polymost gave up on this for the most part and relies on some software render code to do the setup and then has it's own way of cutting the geometry into triangles in real time.
As static doesn't exist, you get computationally heavier 3D preparation that needs to occur constantly, and you get like a gazillion draw calls as it's just difficult to make a reliable model out of this quickly, each frame. But still possible.
Polymer does some extra on top of this but as there is zero precomputation done, light passes like quake has are impossible to perform. Lights basically have to always be dynamic and that can be quite heavy.
A light pass on a quake map is extremely heavy and imagine having to do these in real time (Quake has on/off states and very limited dynamic glow for things like rockets).
Dynamic lights in Build also don't have visibility data or such to fall back on.

In short, clever decisions that make Build what it is just don't translate well in to de-facto rendering practices and it's a constant fight against the current as you have to go against sanity in order to get the real output

[Ninety-Six]

 oasiz, on 15 October 2022 - 09:42 AM, said:

Quake is 3D, but it would be unreasonable to use a modelling tool to do this. Map editor is more of a tool to create "pseudo models" using building blocks that are more suited for 3D geometry.
This then gets chopped to a way more optimized 3D model (and triangles) through an automated compiling tool.

This is what brushes are then, right? The pseudo-models? I remember asking about that in a thread not too long ago.

 oasiz, on 15 October 2022 - 09:42 AM, said:

Wall of text....

I think I get the gist of it, thanks.

So that said, what exactly is required on the end-user's part to make Polymer playable? Some people apparently have little to no issue, but then you have people like ultra who can run modern AAA games but still struggle with polymer. Is it like GZDoom where power is needed in the CPU instead of the GPU (assuming I read that one post correctly...?), or some other component?

For the record I'm not trying to justify the misconception Reaperman was talking about, I'm straight asking (roughly) what kind of specs are needed to run Polymer playably.

[oasiz]

Pseudo-models is not exactly accurate either as they are of course represented by triangles as well in the editor too
Technically you COULD always leave them but it would be very inefficient (This can be done if you surround your map in a box to work around map leaks).
I guess the best analogy is like having rolled out dough and using cut-outs to create shapes. The step I describe is like removing the excess dough.

As for polymer optimizations, I'm no render coder so I can't comment on much.
What I know is that there are a lot of optimizations to be done and that it's more efficient to just redo it at this point.
Performance issues can even come from simple things like driver level optimizations.
As it was never truly finished and/or feature complete, all claims that "it's the future & replacement" are inaccurate. It's still practically in beta.
Much like many early system emulators, performance may vary wildly as focus is put on functionality instead of performance tricks at first.

[Reaper_Man]

I agree, it's almost certainly a problem of implementation than of raw hardware power. So I don't think it's a matter of how powerful of hardware you have, or how well you can run other modern engines (or rather, modern renderers). I have 3 computers in my house, including a top of the line VR system. All of my hardware is AMD processors and Nvidia cards, and I have no problems whatsoever running the worst things Polymer can throw at me. I still wouldn't feel comfortable saying that's the best setup since other people with similar hardware do experience problems.

While working on performance and optimizations for AWOL, we ran into a truly psychotic variety of issues (even with just 3D models, not even Polymer lighting) that leads me to understand there is no single smoking gun causing problems. We have players on modern high-end hardware that both do and do not experience problems. The problems seem to be most commonly linked to AMD graphics cards, however we have players with 6800 XTs and some experience issues and others do not. We have players on lower end hardware with no issues whatsoever, and other players who experience performance issues so bad that the game is a slideshow and yet immediately clears up once they turn 3D models off. And just every variety of player experience and hardware in between.

Unfortunately it just seems like you can either run Polymer or you can't, and if you can't then you're SOL because the problem is Polymer and not you or your hardware.

[Mark]

Reaperman, I wonder what your framerate would be running my Quest Town project on your high end system. Part of it is a large outdoor area with lots of models and lights. I get anywhere from 8 to 25 fps running my ancient system out there. My screenshot shows were the lowest rate is. Wide open with a view of everything.

Attached thumbnail(s)

• 

[oasiz]

A lot of it is likely driver level optimizations simply.
Drivers are mostly a bag of speedhacks to make your games run smoother or stabler.
It's almost like dealing with emulator game specific speedhacks. Watch the perf tank or behave strangely when you do something as simple as change the .exe name to something else.
Not guaranteed to happen but it can happen.

Newer drivers also may change some implementations and break old stuff in unexpected ways.
Software development is software development...

[Mark]

I'm forced to use a 3+ year old driver because Nvidia decided to remove all 3d Glasses support after that.

[ck3D]

 Mark, on 16 October 2022 - 01:26 PM, said:

Reaperman, I wonder what your framerate would be running my Quest Town project on your high end system. Part of it is a large outdoor area with lots of models and lights. I get anywhere from 8 to 25 fps running my ancient system out there. My screenshot shows were the lowest rate is. Wide open with a view of everything.

This looks great, Mark!

[Mark]

Thanks.

[Reaper_Man]

 Mark, on 16 October 2022 - 01:26 PM, said:

Reaperman, I wonder what your framerate would be running my Quest Town project on your high end system. Part of it is a large outdoor area with lots of models and lights. I get anywhere from 8 to 25 fps running my ancient system out there. My screenshot shows were the lowest rate is. Wide open with a view of everything.

Sure, got a download link somewhere?

[Mark]

https://forums.duke4...post__p__288773

[Tea Monster]

“Fixing” Polymer would involve deleting the source code and starting from scratch.

[Ninety-Six]

 Tea Monster, on 19 October 2022 - 04:53 AM, said:

“Fixing” Polymer would involve deleting the source code and starting from scratch.

TX showed a few screens of working on Polymer not too long ago. Does anyone know if that's still happening?

[Mark]

Last I heard, TX had some changes off to the side that he is waiting for the right time to merge with the main branch. No idea what changes or fixes.

[dandouglas]

I made a tin of throwable soup.

[Šneček]

 dandouglas, on 22 October 2022 - 02:28 AM, said:

I made a tin of throwable soup.

What is worth more, art or life? Is it worth more than food? More than justice? Are you more concerned about the protection of a painting or the protection of our planet and people?

BTW, can the player throw that ketchup on all the paintings or just on poor Gogh?

[Tea Monster]

Quote: "Stuff Oasiz and Reaper_Man said"
Shoe-horning all this rendering tech into an old 2.5D engine is a huge technical achievement. Quite amazingly, some people tried, but it's very problematical. Speed isn't the only problem that Polymer has. Shader issues and an ancient model format that won't hold model normals correctly are others that nobody talks about. There is a chance that someone will fix one of these issues, but there is no telling how long you are going to be waiting for someone to do this. It could be year, it could be much longer.

"Just make your Duke game in Unreal" say lots of people. This is a great idea. The problem with making your level in Unreal is that after you've made your level to look like what you want it to, you then have to set up the game part of your game. How do enemies move, what happens when they shoot you, how do they find you and what happens when you interact with the world? What does your UI look like? This is all stuff you have to add in yourself. There are kits you can buy that will do a lot of this for you and you just plug in the values you want to emulate certain games, but it's a lot of work. Not impossible, but a lot of work. It's not as easy as "Just make it in Unreal".

The other option is to take a another, more modern game, where they have already set up all the gameplay elements, and use that to make your Duke game. Change the config files so that the movement and behaviours match Duke 3D more closely. That's a lot easier than creating all your 'game' from scratch. That is what Serious Duke 3D did, and did quite successfully. Is it Duke Nukem 3D? No, but if you wanted to make something completely faithful to what you can do with Duke Nukem 3D, you'd make it with Duke Nukem 3D. If you want to do something modern, use a modern engine. At the moment the most complete one that exists is probably Serious Duke 3D on the Serious Sam engine. There have also been attempts to turn other games into Duke Nukem games with GoldSrc (Cataclysm - files are available on line), Source, Quake I. Pick one you are comfortable with, download the existing mod and start building on it.

If you want to wait for Polymer to be 'fixed' you could be waiting an awful long time.

[Reaper_Man]

I completely agree.

I don't understand / don't agree with the "just make it in Unreal" responses. As you said, you're not making "a Duke Nukem 3D" game, you're making a new game. Which is awesome! And fun! But also a ton of work. A lot more work than you'd ever imagine. Not everyone is up for that task - which is fine, it's why modding existing games is a thing people do. But it also means you're limited by what those games and engines are capable of.

If you want to make "a Duke Nukem 3D" game, use EDuke. If you want to make "a Duke Nukem 3D" game that looks modern, use Polymer and cross your fingers. If you use Polymer and your performance sucks, then consider A.) not making it look modern or B.) not making "a Duke Nukem 3D" game. There is no choice C.), unless you consider "learning how to write a modern 3D renderer" or "wait around for someone else to do it" viable options.

[Micky C]

 oasiz, on 13 September 2022 - 01:14 PM, said:

Quick idea that popped in to my mind, basically combining the more traditional SOS vent style but now with TROR and sprite constructs.
You could mask this better with some custom textures (i.e. modified stock for sides of vent).. or just not use slopes

This should give some interesting ways to create airducts.... I guess you can colour them green and finally have your mario pipes in duke.
Of course you could make everything with sprites but what's the fun with that.

I have no clue if these "mid-room TROR" ducts have been done before but now you know.

I actually did that a few years ago for AMC Squad episode 2. Mikko’s Energia map had sprite vents underwater, but there were blocking issues, so I converted the interior into sectors using SOS, while leaving the exterior as sprites.

Well, I don’t think I used TROR for it though.

[dandouglas]

I made a quick motorway intermission sequence to slip between a couple of maps, with a daft little surprise if the player presses fire

[Tea Monster]

 Reaper_Man, on 27 October 2022 - 08:53 AM, said:

I don't understand / don't agree with the "just make it in Unreal" responses. As you said, you're not making "a Duke Nukem 3D" game, you're making a new game. Which is awesome! And fun! But also a ton of work. A lot more work than you'd ever imagine. Not everyone is up for that task - which is fine, it's why modding existing games is a thing people do. But it also means you're limited by what those games and engines are capable of.

Looking at a lot of indie games that are popping up all over the place, if you started with a kit for a FPS, a talented team could put something credible together with a bit of dedication. Especially nowadays, it doesn't have to be AAA graphics level.

[Mark]

I had nothing better to do so I installed one of TeaMonster's WIP monsters into eduke. I drew in the red eye because TM hasn't gotten around to adding them on the model yet. I couldn't wait and wanted to post this shot because I thought it was so kick ass looking. He said go ahead.

Attached thumbnail(s)

• 

[Mark]

Now THIS is a boss fight.

Attached thumbnail(s)

• 

[dandouglas]

I made an interactive photo booth

[Mark]

Amazingly creative as usual.

[Danukem]

 dandouglas, on 03 November 2022 - 03:56 AM, said:

I made an interactive photo booth

What happens if you leave the booth during the countdown? Does the photo still come out and is it different?

[dandouglas]

 Danukem, on 11 November 2022 - 11:27 PM, said:

What happens if you leave the booth during the countdown? Does the photo still come out and is it different?

Ah, I've actually locked player movement for the duration of the countdown - thinking perhaps if the player's health is below a certain point it could print out a photo of Duke's face all bashed up though.