Raze officially revealed!

[Tea Monster]

I meant to say that Polymost was very primitive and that Polymer was crap. I edited my original post.

Polymost has no lighting effects at all. Polymer was never finished. Apart from never being optimised, the specular/gloss shader is borked.

[Kinsie]

Plagman (Author of Polymer) only had some limited time to put that in, and he now works at Nvidia.

He's been at Valve for quite a while now, actually, working on hardware and Linux stuff.

[Tea Monster]

... and NOT Polymer! Actually, some work has been done on Polymost recently. There were still problems with rendering skyboxes till recently. How doable would it be to get multiplayer working and/or get GZDoom's PBR renderer working?

[Phredreeke]

Plagman (Author of Polymer) only had some limited time to put that in, and he now works at Nvidia. Given that there has been nobody else having a go at it (I am not sure if the source is even available), it is simply existing.

The source is still available, otherwise EDuke32 wouldn’t build with it.

Anyway, good luck on this project. I assume the focus will be on the Build-side of things and game specific code will more or less be left as is?

... and NOT Polymer! Actually, some work has been done on Polymost recently. There were still problems with rendering skyboxes till recently. How doable would it be to get multiplayer working and/or get GZDoom's PBR renderer working?

Multiplayer would need to be done game side for each game

[Nash]

[Graf Zahl]

That's the plan - so don't expect fancy effects and cool lighting right out of the box. I think the Polymer renderer is a great example of something that got its effects added before the foundatiin was working, and we all know how it ended up (... that thing that's slow ...) Once there is a solid foundation these things can be added.

Plagman (Author of Polymer) only had some limited time to put that in, and he now works at Nvidia. Given that there has been nobody else having a go at it (I am not sure if the source is even available), it is simply existing. Ion Fury does not target Polymer either way, preferring software or Polymost at best.

The Polymer source is of course available in EDuke's repo. But it's old code, targeting an obsolete OpenGL version and using lots of deprecated features. It's also the same style as the rest of the engine: Procedural code using lots and lots of global variables. And everyone knows: Such code can be hard to read. The main issue is the performance, of course, but with the code structure it's going to be hard to find out what precisely the problem is. Most likely some unoptimized data structures.

I know icecoldduke has been doing a lot of high end Duke3D stuff in a similar fashion as dpJudas, but Ice has a habit of not finishing things. Which sucks, because the stuff he has worked on could have been interesting for this contraption.

Yes, that was the same impression I had.

Using Polymost gives one a stable base but its also not the latest OpenGL.

Well, yes and no. I completely separated Polymost from OpenGL so that all Polymost does is generating polygons and sends them off to the backend, which is OpenGL 3.3 with options to use 4.5 features. This has the advantage that I can drive the same backend with output from a different renderer, meaning I can add features to the backend without having to bother with Polymost itself.
Polymer, on the other hand, is so tightly coupled with OpenGL that trying to move it anywhere else is magnitudes harder.

Okay, so this is more like a frontend to various game modules using the Build Engine (given how Build is simply a renderer). That sounds a bit like Retroarch to me honestly.

I think BuildGDX is the best example here - it shares the renderer, the sound system and the input/system interface code across games. I also generalized some game data where it was doable, e.g. the mapinfo records. But surely the game modules themselves never interact with each other.

I have it on the record that this thread is what inspired you.

Yes, that's what started it. Trying to get Duke to work and never really managing to get what I wanted...

Polymost has no lighting effects at all. Polymer was never finished. Apart from never being optimised, the specular/gloss shader is borked.

I'm not an expert here - I noticed that on some surfaces it looks a bit off - what precisely do you mean by "borked"?

Anyway, good luck on this project. I assume the focus will be on the Build-side of things and game specific code will more or less be left as is?

For the most, yes. Since this is 5 games essentially,it'd be a bit overwhelming to work on the game code in parallel to the actual engine. Most of the games - Duke and Blood excluded - have the little problem of not having a modding community anyway, so it's not really the part to sink time in. Of course I had to take apart a few things in the game code to get things working, like the menus - for the sake of efficiency it was unavoidable to use a common menu engine, for example. PCExhumed doesn't even have a real options menu so this seemed like a good investment to build something with GZDoom's menu engine.

... and NOT Polymer! Actually, some work has been done on Polymost recently. There were still problems with rendering skyboxes till recently. How doable would it be to get multiplayer working and/or get GZDoom's PBR renderer working?

Multiplayer would need to be done game side for each game

Thanks for pointing out the multiplayer issue. Yes, it needs to be done per game - and the existing implementations are very different, from being functional to being broken or still in development. I currently don't have an idea how feasible the existing code for the various games even is. I'll be honest here: Unless someone else is helping out here, I won't be able to maintain the multiplayer/networking side. That'd completely bog me down and leave no room for the things I'm really interested in, like working on the renderer.

[Tea Monster]

What I mean about the shader problems is that the gloss/specular shader that Polymer uses does not behave like most other gloss/spec (non PBR) shaders. If you create a series of diffuse, specular, normal and gloss maps for Polymer, the gloss and specular won't look like they do in substance painter, substance designer, materialize marmoset toolbag or any other soft that is used to create these things. In Polymer, the gloss map is in the alpha of the specular map. In the past, people have applied hacks in the def files to run the amount of specular highlight up to 2x normal to get stuff to look 'right'. This is, of course, completely crap!

We did a mod called Hollywood Holocaust Rethinked ( a parody of reloaded) where we tried to make a modern game look in Polymer. I was creating textures in substance painter for models and it would all look as it should, then when it got into Polymer - uh uh! We spent MONTHS trying to get the gloss and spec maps to appear like they did in the creation software. In the end, we gave up on using gloss maps because it was just too much hassle to fart around with figures in the def file to try to get stuff to look right. At one point there was a bug where if you looked at an object from one side, you would see it at 100 gloss range, so it was nearly a mirror. If you walked around the object and viewed it from the other side, then it would appear nearly matt. Crazy.

There are also problems with alpha. If there are two alpha textures on top of each other, they won't render. We had to wind up cutting the tops off of all our pinball machines as the tops were all opaque!

EDIT: Do you have a method of contacting IceColdDuke? If not, I can pass on a message if you like. His working relationship with the EDuke32 team could be just a wee bit heated at times, though they seem to be on good terms at the moment.

[ZZYZX]

Y'all are calling Polymer bad but it actually has correct dynamic light shadows working! smh.

On topic: looks great, though not quite sure why we need a new Build port if it by design (each game has different scripting) cannot support throwing CON into the window and writing stuff in DECORATE/ZScript...
Or will it actually support better modding capabilities? And how?

[Rachael]

though not quite sure why we need a new Build port

This mainly focuses on usability right now, that's the main point of it. Even EDuke32 which is arguably probably the best of the Build ports feels a bit janky, particularly with mouse movement. The goal of this port is to try and make it feel somewhat more natural, along with a host of other things. It has a lot of GZDoom-related options in it, as well, including GZDoom's post process effects (yes, that includes Bloom and faking increased color ranges with dithering).

[Graf Zahl]

On topic: looks great, though not quite sure why we need a new Build port if it by design (each game has different scripting) cannot support throwing CON into the window and writing stuff in DECORATE/ZScript...
Or will it actually support better modding capabilities? And how?

Why? Why not? I started with this because I had problems getting VSync to work properly in EDuke and because I wanted true color rendering back and a better music system than the Windows system MIDI synth. I tried BuildGDX but had other problems with that (e.g. the Java backend not recognizing all keys on my keyboard - and its VSync also did not work) From that I just went on, ending up changing more and more until I was able to plug the entire GZDoom backend into it.

You may ask the same question about the retro Doom ports. We already have PrBoom - do we really need Crispy and Retro? Apparently their developers have fun doing it. Shouldn't that be enough?

[Tea Monster]

The more, the merrier!

[Redneckerz]

He's been at Valve for quite a while now, actually, working on hardware and Linux stuff.

I like this sideinfo. Thank you for bringing me up to speed.

The Polymer source is of course available in EDuke's repo. But it's old code, targeting an obsolete OpenGL version and using lots of deprecated features. It's also the same style as the rest of the engine: Procedural code using lots and lots of global variables. And everyone knows: Such code can be hard to read. The main issue is the performance, of course, but with the code structure it's going to be hard to find out what precisely the problem is. Most likely some unoptimized data structures.

I fully expect drfrag to do an LZ version of this whenever this comes around

Well, yes and no. I completely separated Polymost from OpenGL so that all Polymost does is generating polygons and sends them off to the backend, which is OpenGL 3.3 with options to use 4.5 features. This has the advantage that I can drive the same backend with output from a different renderer, meaning I can add features to the backend without having to bother with Polymost itself.
Polymer, on the other hand, is so tightly coupled with OpenGL that trying to move it anywhere else is magnitudes harder.

I was going to ask since when Polymost gained OpenGL3 and 4 capabilities since for the longest time it was an OpenGL1.1 part. But then i remembered that the Ion Fury devs did some extensive retooling. I reckon this also explains why GZDoom's post-processing framework works - Its not linked to the primary renderer sort to say, but Polymost is just a backend, in the same vein as this port is a backend to the 5 game modules.

This does open up a lot of exciting things, first and formost. Perhaps this GZBuild or whatever its named is also a good testbed to get the old lightmaps branch up and running? Obviously, i understand that the first and formost nature is stability (Plus some fancy effects that you already have, judging by Rachaels post) and compatibility, and that GZBuild is a universal framework of some sorts - Indeed, similar to BuildGDX, and with most of the actual rendering done by EDuke32/Polymost.

If that is more or less the case, then that would be certainly enticing, and not just for this community alone.

It has a lot of GZDoom-related options in it, as well, including GZDoom's post process effects (yes, that includes Bloom and faking increased color ranges with dithering).

I love the impression you make with this. On the surface, it reads like a complete Frankenstein contraption, but the more i think about it based on what has been provided so far, i can tell what this attempts to set out to do.

[Graf Zahl]

I was going to ask since when Polymost gained OpenGL3 and 4 capabilities since for the longest time it was an OpenGL1.1 part. But then i remembered that the Ion Fury devs did some extensive retooling. I reckon this also explains why GZDoom's post-processing framework works - Its not linked to the primary renderer sort to say, but Polymost is just a backend, in the same vein as this port is a backend to the 5 game modules.

Actually, I ripped out all OpenGL code from Polymost, there is nothing left from the GL 1.1 code path and even less from the "modern GL" code path. This part is entirely new code, as is the texture manager. To be clear: There is not a single line of OpenGL accessing code left from EDuke. I also completely rewrote the shader it uses for rendering on modern hardware.

This does open up a lot of exciting things, first and formost. Perhaps this GZBuild or whatever its named is also a good testbed to get the old lightmaps branch up and running?

Probably not. Doom's geometry is mostly static, there lightmaps work. In Build sectors can move, in such cases it is entirely impossible to generate lightmaps at all!

Obviously, i understand that the first and formost nature is stability (Plus some fancy effects that you already have, judging by Rachaels post) and compatibility, and that GZBuild is a universal framework of some sorts - Indeed, similar to BuildGDX, and with most of the actual rendering done by EDuke32/Polymost.

Not quite. Due to the extensive changes and code replacements it should be clear that the result will require a bit of time to iron out all the issues. Don't worry, most of this will be a public testing phase, but there's a few things I need to take care of first or people may be a bit annoyed about some usability issues.

I love the impression you make with this. On the surface, it reads like a complete Frankenstein contraption, but the more i think about it based on what has been provided so far, i can tell what this attempts to set out to do.

Don't worry, it's not Frankenstein's monster. These things fit together a lot better than this may sound. They were already cleanly separated subsystems before (except the menus, that is - and they are also the part that caused the most problems - but still less work than fixing up all the needed things in the existing menu code that came with the games - all 5 of them), so they were replaced one by one.

[Dancso]

If this ends up supporting Witchaven (2) with improved controls, i may finally bother finishing the damn game
Pretty excited regardless!

[Graf Zahl]

If this ends up supporting Witchaven (2) with improved controls, i may finally bother finishing the damn game !

Last time I tried Witchaven with BuildGDX I ran away in horror. I've never seen a game with such botched player controls and movement logic. IO found it virtually unplayable.
Sadly replacing that may be a bit too problematic - altering fundamental game control will always cause problems with what the game expects.