[Micky C]

I'm pretty impressed with how realistic the renderer is looking, especially at this early stage. Reinvigorates my motivation to make a polymer map!

[Mark]

OK. I was trying to boil it down to the basics. That a map with no sprites or lights, just sector geometry will see an increase in FPS. Thats what I wanted to know. Thanks.

[icecoldduke]

A few people wanted to know were PolymerNG is at. I finally got all the setup stuff done(there was a lot of work to do there), and the UI is rendering. Framerate is capped at 60hz right now. Keep in mind this is a debug build, and I have a lot of debug stuff turned on. The GPU time goes down to about 0.8 when all the D3D12 debug layer stuff is turned off, and im not running through nsight.

CPU Time: This is how long the Duke Game Thread takes to execute.
GPU Time: How long the graphics card takes to chew on the graphics data.



Link to fullsize image:
http://s1175.photobu...wn2ses.png.html

EDIT: Fixed palette issues, and updated the image.

[Steveeeie]

What map are we going to serve to make a material in this engine?

I was hoping, base-color, metallic, roughness and normals like UE4

[icecoldduke]

 Steveeeie, on 22 December 2015 - 07:28 AM, said:

What map are we going to serve to make a material in this engine?

I was hoping, base-color, metallic, roughness and normals like UE4

I posted this on the first page of this topic: Albedo, Normal, Spec, Spec2, SSS Maps, Displacement, Mask, Glow, and Animated Textures.

[TON]

Eduke32 also supports dds texture format:

 Plagman, on 07 June 2012 - 06:11 AM, said:

And you can actually use DDS directly into EDuke32.

 Diaz, on 07 June 2012 - 06:46 AM, said:

Lol, didn't know about that. I'm not much into that format - is the compression better than .PNG or is it lossy?

 Plagman, on 07 June 2012 - 09:12 AM, said:

No, it's lossy; the value of DDS is your textures are already DXT-compressed offline, meaning you can just pass them through the GPU without having to run through expensive texture compression at pre-caching time. It also includes a full mipmap chain, it's fully ready for the GPU out of the box. In that spirit it's the same as our compressed on-disk texture cache.

EDuke32's support for DDS comes from KPLIB and is more a convenience than anything else, since it uncompresses the DXT data in software and discards the mipmap when reading it from disk (after that, hightile re-compresses it and re-generates mipmaps like every other image format and writes it to the disk cache).

 wayskobfssae, on 07 June 2012 - 03:00 PM, said:

Eduke32 supports DDS files? Dang, didn't even know that. I wouldn't mind using that instead if it means better memory management and load times... provided that photoshop's DDS convertor can generate its its alpha channel the PNG's transparency. I don't think I've ever tried that.

[icecoldduke]

 TON, on 22 December 2015 - 12:30 PM, said:

Eduke32 also supports dds texture format:

As I've said before I'd prefer to only support TGA, and let the engine DXT compress those images for you. I can't vouch for the compression quality of various image exporters, but I'll keep the DDS format support if its in there.

I know TON post is about DDS textures(which are DXT compressed), if I allowed usage of PNG textures, the engine would have to decompress the PNG image and re-compress it to DXT format for image upload. The only advantage PNG format gives you, it saves HD space on the dev machines.

[Hendricks266]

It seems like wayskobfssae completely missed the second part of Plagman's post.

Regardless, PolymerNG must load assets through the def parser, and it must keep compatibility with all formats we support now. KPLIB should be satisfactory for loading PNG/JPG/GIF/TGA/BMP/PCX, but its DDS implementation is counterproductive.

[icecoldduke]

 Hendricks266, on 22 December 2015 - 12:52 PM, said:

It seems like wayskobfssae completely missed the second part of Plagman's post.

Regardless, PolymerNG must load assets through the def parser, and it must keep compatibility with all formats we support now. KPLIB should be satisfactory for loading PNG/JPG/GIF/TGA/BMP/PCX, but its DDS implementation is counterproductive.

Why is the DDS implementation counter productive?

[Hendricks266]

 icecoldduke, on 22 December 2015 - 12:55 PM, said:

Why is the DDS implementation counter productive?

 Plagman, on 07 June 2012 - 09:12 AM, said:

EDuke32's support for DDS comes from KPLIB and is more a convenience than anything else, since it uncompresses the DXT data in software and discards the mipmap when reading it from disk (after that, hightile re-compresses it and re-generates mipmaps like every other image format and writes it to the disk cache).

We should use the DXT data in the DDS since the whole point of using DDS is having that pre-calculated.

[icecoldduke]

 Hendricks266, on 22 December 2015 - 12:56 PM, said:

We should use the DXT data in the DDS since the whole point of using DDS is having that pre-calculated.

The issue I have with DDS is I can't vouch for the quality of the DXT compression used in whatever exporter people use. People also need to use the right DXT compression method for there normal maps or you can get a mess.

I don't mind supporting those formats for legacy content, but for newer content people should use TGA. Taking compressed data(e.g PNG) and converting it to DXT data can do bad things to textures . It's always best to take raw data and do compression off of that.

[Hendricks266]

 icecoldduke, on 22 December 2015 - 01:02 PM, said:

Taking compressed data(e.g PNG) and converting it to DXT data does bad things to textures .

PNG is lossless, damnit. How many times do I have to go through that in this thread?

 icecoldduke, on 22 December 2015 - 01:02 PM, said:

The issue I have with DDS is I can't vouch for the quality of the DXT compression used in whatever exporter people use. People also need to use the right DXT compression method for there normal maps or you get a blocky mess(e.g. https://udn.epicgame...MapFormats.html).

It seems like you're intent to hold content creators' hands too hard. We simply have to document the following things:

1. Don't use PNG optimizers that mangle unseen data in the alpha channel.
2. Use PolymerNG's custom compressor to make DDS files from your lossless PNGs or TGAs.

Once PolymerNG is more developed, I'll look into PNGOUT and talk to Ken if it needs a new option.

It might be possible for #2 to detect when an alpha channel has been mangled and warn the user. IIRC, there are clear signs if that it the case.

[icecoldduke]

 Hendricks266, on 22 December 2015 - 01:07 PM, said:

PNG is lossless, damnit. How many times do I have to go through that in this thread?

The algorithm is lossless you are correct, but I have seen various exporters(including Photoshop) mangle the output so the data was actually lossly. I have personally seen(and have had to deal with) graphical errors due to content loaded from PNG's(and it wasn't just alpha channel errors). The answer was to tell the content guys to export the data as TGA's and let the engine do the compression. People are going to have various issues with the new renderer, and it would be easier on my self if content guys would stick with TGA, so I can rule out any content issues right off the bat.

Content guys are going to be exporting there data using a variety of different tools, and I don't have time to support them all .

 Hendricks266, on 22 December 2015 - 01:07 PM, said:

It seems like you're intent to hold content creators' hands too hard. We simply have to document the following things.

It's always best to give content creators a clear set of guideless that are guaranteed to produce the best results, and force content developers to adhere to those standards. It's not that hard to export content to TGA's.

[Hendricks266]

Dec 17 21:39:59 <icecoldduke> I don't mind supporting more formats, but I have seen awful artifacts from PNG's, especially with Normal maps
Dec 18 00:46:40 <Hendricks266> your argument is completely invalid
Dec 18 00:46:51 <Hendricks266> every normal, specular, diffuse, glow, and detail map in the HRP is PNG

I think we still have some JPEG Polymost stuff but that's beside the point.

[icecoldduke]

 Hendricks266, on 22 December 2015 - 01:23 PM, said:

Dec 17 21:39:59 <icecoldduke> I don't mind supporting more formats, but I have seen awful artifacts from PNG's, especially with Normal maps
Dec 18 00:46:40 <Hendricks266> your argument is completely invalid
Dec 18 00:46:51 <Hendricks266> every normal, specular, diffuse, glow, and detail map in the HRP is PNG

I think we still have some JPEG Polymost stuff but that's beside the point.

I stand by the workflow I'm purposing, it minimizes errors and that's what we need . I'll add support for those other formats, but I won't have time to offer technical support to teams that don't follow the recommend workflow.

So instead of legacy mode, there will be "technical support" and "non technical support" modes.

[blizzart]

 icecoldduke, on 22 December 2015 - 01:43 PM, said:

I stand by the workflow I'm purposing, it minimizes errors and that's what we need . I'll add support for those other formats, but I won't have time to offer technical support to teams that don't follow the recommend workflow.

EDIT: My statement in that instant message was bad verbage on my part.

Nice to see, that formats like JPG and PNG will be supported, too. My mod uses a huge amount of new textures and has already a size of 1.5 GB, although I´m using JPGs and PNGs only.

Anyways, I have three questions about the new renderer:

1.) Though I´m not using Win 10 and won´t be able to use DX12, is there already a release date for Vulkan?

2.) Can I keep working on my Polymer mod and switch easily to the new renderer afterwards or do you suggest to wait for a working version of it?

3.) What kind of video cards are required for the new renderer? Actually I´m running Polymer on my notebook with a nVidia GT635M, which is a little less powerful than a GTX 460. Polymer runs very well with it, but will I still be able to run the new renderer with it or is a more powerful card recommended?

[icecoldduke]

 blizzart, on 22 December 2015 - 02:36 PM, said:

Nice to see, that formats like JPG and PNG will be supported, too. My mod uses a huge amount of new textures and has already a size of 1.5 GB, although I´m using JPGs and PNGs only.

Anyways, I have three questions about the new renderer:

1.) Though I´m not using Win 10 and won´t be able to use DX12, is there already a release date for Vulkan?

2.) Can I keep working on my Polymer mod and switch easily to the new renderer afterwards or do you suggest to wait for a working version of it?

3.) What kind of video cards are required for the new renderer? Actually I´m running Polymer on my notebook with a nVidia GT635M, which is a little less powerful than a GTX 460. Polymer runs very well with it, but will I still be able to run the new renderer with it or is a more powerful card recommended?

1) The Vulkan release date hasn't been released yet.

2) PolymerNG will load Polymer mods, but all the new graphics features in PolymerNG won't be enabled until you enable them.

3) I haven't flushed out min spec yet.

[Tea Monster]

How are you going to enable HDR lighting? Will it be via cubemaps, or general dynamic lighting?

How much control will we have over individual materials?

[icecoldduke]

Removed will post a comprehensive guide later on.

[Mark]

You lost me. Does this mean our simple 3 or 4 line def file entry for a model goes flying out the door and replaced with the above?

[Hendricks266]

And here I thought you were holding hands too hard.

[icecoldduke]

 Mark., on 22 December 2015 - 04:08 PM, said:

You lost me. Does this mean our simple 3 or 4 line def file entry for a model goes flying out the door and replaced with the above?

No, the above is for people that want more granular control over how there content is renderer. You don't have to do any of what I posted above, you can just toggle all the render params I have exposed in the materials. You CAN expand on those params to make custom content IF you want too .

[Mark]

whew.

[icecoldduke]

 Hendricks266, on 22 December 2015 - 04:11 PM, said:

And here I thought you were holding hands too hard.

I should know better, I should wait to post a comprehensive guide before I post random bits of info that scare the content guys away .

[Steveeeie]

 icecoldduke, on 22 December 2015 - 04:15 PM, said:

I should know better, I should wait to post a comprehensive guide before I post random bits of info that scare the content guys away .

*hangs coat back up*

[Tea Monster]

Hendricks266, here is your golden opportunity to put a node-based material set-up into EDuke!

[blizzart]

 icecoldduke, on 22 December 2015 - 02:45 PM, said:

1) The Vulkan release date hasn't been released yet.

2) PolymerNG will load Polymer mods, but all the new graphics features in PolymerNG won't be enabled until you enable them.

3) I haven't flushed out min spec yet.

Thank you for your answers.

I´ve just read this: https://www.khronos.org/vulkan, so I think it shouldn´t take to long until I could get my hand on your work.
Also, it´s great to hear that the new renderer will be downwards compatible.

Will there be any fallback capatibility, so that content created for the new renderer will also be running with Polymer (by turning off features, that Polymer doesn´t know)?

[icecoldduke]

 Tea Monster, on 22 December 2015 - 05:43 PM, said:

Hendricks266, here is your golden opportunity to put a node-based material set-up into EDuke!

That would be fantastic if someone could make a node based material system happen.

 blizzart, on 22 December 2015 - 07:07 PM, said:

Thank you for your answers.

I´ve just read this: https://www.khronos.org/vulkan, so I think it shouldn´t take to long until I could get my hand on your work.
Also, it´s great to hear that the new renderer will be downwards compatible.

Will there be any fallback capatibility, so that content created for the new renderer will also be running with Polymer (by turning off features, that Polymer doesn´t know)?

Mods made in PolymerNG should be some what backwards compatible to the previous renderer. Any new PolymerNG features obviously won't work, and any materials that use custom shaders will not be backwards compatible.

[Kyanos]

Will PolymerNG have the same rendering characteristics as Polymer?

Specifically I'm asking about the lack of multiply skyboxes in one map, and the way level geometry get renders through a parallax sky that would not be drawn in Classic or Polymost.

EDuke32 Wiki - Polymer_Deficiencies

Quote

limited to one skybox
level geometry is displayed through skyboxes when it should not

[icecoldduke]

 Drek, on 24 December 2015 - 08:32 AM, said:

Will PolymerNG have the same rendering characteristics as Polymer?

Specifically I'm asking about the lack of multiply skyboxes in one map, and the way level geometry get renders through a parallax sky that would not be drawn in Classic or Polymost.

EDuke32 Wiki - Polymer_Deficiencies

I can't promise content made for Polymer will render the same under PolymerNG, it should, but I can't promise anything.