[Kyanos]

icecoldduke, on 02 June 2016 - 03:29 PM, said:

Your guys's stuff is too high poly.

No some of the stuff you are dealing with is too high poly.

It's not all like the HRP enemies, just because that project went WAY too far with vert anims doesn't mean you should cut it.

edit; we asked for MD5s with skeletons years ago, I thought the 10MB cycloid was a trolling effort to get a better format when I first saw it

[TerminX]

Where do you get that 3 GB figure from? That seems like an awful lot. Aside from the question of how you get 3 GB of data from the ~60 MB of md3 files contained in the HRP currently, there is also the point to be made that none of this data is all going to be in memory at once.

I think you should implement the model rendering with frame updates uploaded on the fly like Polymer does it and see if there's even a problem with what you want to do with virtual texturing. Model rendering was never a choke point in Polymer so I don't think you'll have an issue.

[icecoldduke]

Drek, on 02 June 2016 - 03:37 PM, said:

No some of the stuff you are dealing with is too high poly.

It's not all like the HRP enemies, just because that project went WAY too far with vert anims doesn't mean you should cut it.

Vertex count for all models in the HRP.
Vertex counts for HRP models.

My favorite so far:
Fan sprite.

D:\BlackenmaceStudios\DukeNukem\Tools\dukenukem\highres\
sprites\props\0407_fansprite.md3: VertexCountPerFrame 9036 IndexCount 9036 NumFrames 16 Total Vertexes 144576

Stripper

D:\BlackenmaceStudios\DukeNukem\Tools\dukenukem\highres\
sprites\characters\1312_stripper.md3: VertexCountPerFrame 4080 IndexCount 4080 NumFrames 91 Total Vertexes 371280

Why does the fan have 9036 vertexes when the stripper only has 4080?

[Hendricks266]

HiPolyBash, on 02 June 2016 - 03:14 PM, said:

I'm not suggesting that everything be thrown under the bus specifically for .MD3 support but at the very least it should be there so things just 'work'. You can encourage content creators to go back and optimize their content but it's entirely unacceptable for it to just not work at all in favor of pushing the new features and support.

Quoted for truth. If vertex animated models take up too much VRAM, sort them from largest to smallest and start pruning from the top. Solved.

[Kyanos]

icecoldduke, on 02 June 2016 - 03:55 PM, said:

Vertex count for all models in the HRP.
Vertex counts.

You've doubled up some, and those top examples are the ones we all agree should get skeletons. That has polymost and polymer versions included.

[MusicallyInspired]

Tea Monster, on 02 June 2016 - 02:51 PM, said:

Very little of the HRP is compatible with either Polymer or PolymerNG. Virtually all of them need to be remade.

I don't know what you guys are talking about here. From what you're saying one would get the impression that half the stuff in the HRP should look like unfinished trash but it doesn't. Everything looks fine when I play. Can you show me some examples with screenshots? I don't get any performance hits when I play with Polymer either. Framerate might buckle every now and then when a LOT is going on but other than that I get pretty smooth framerates across the board.

As to performance hits in Polymost, I've never experienced any slowdowns in Polymost even on my older 512MB ATI card that had major problems with Polymer.

HiPolyBash, on 02 June 2016 - 03:14 PM, said:

especially when the majority of current content runs without a hitch.

This.

[icecoldduke]

TerminX, on 02 June 2016 - 03:54 PM, said:

Where do you get that 3 GB figure from? That seems like an awful lot. Aside from the question of how you get 3 GB of data from the ~60 MB of md3 files contained in the HRP currently, there is also the point to be made that none of this data is all going to be in memory at once.

I think you should implement the model rendering with frame updates uploaded on the fly like Polymer does it and see if there's even a problem with what you want to do with virtual texturing. Model rendering was never a choke point in Polymer so I don't think you'll have an issue.

You know of one the projects I've shipped, you should know when I say that if we upload model data each frame, it will tax the virtual texturing system . I want to reserve main ram -> vram transfers for virtual texturing only.

[Tea Monster]

Are you talking actuall polygons or the size on disk of the MD3 file?

As an example, the existing Duke model is 14.8k Tris. That is including Duke, the shotty and the jetpack.

The MD3 on disk is just over 12mb (not including textures).

The same model, with the same animations and vertex count, is just about the size of a floppy disk when converted to FBX.

[icecoldduke]

Right now we are talking about the model cache. Uncompressed vertex data that is vram ready is 2gb of data uncompressed and ~50mb compressed. To load in all this data, it would hurt load times. I hear you saying "well just use md3 and not the model cache", but that would mean I would still need upload all the model vertex data * numframes to vram, because I don't want that data to go across the bus. So in VRAM you are looking at 2gb of data if you have all of the assets in your maps.

[Tea Monster]

You are not hearing that from me. MD3 was never designed to do any of this. It's old and you can't get reliable tools for it any more. Working with it and getting it to behave is a royal pain.

[icecoldduke]

Tea Monster, on 02 June 2016 - 04:41 PM, said:

You are not hearing that from me. MD3 was never designed to do any of this. It's old and you can't get reliable tools for it any more. Working with it and getting it to behave is a royal pain.

The MD3 format is not the issue its (Vertex * NumVertexs) * numFrames = too_much_data. I don't want to move all that data across the bus every frame, I want to leave the bus free for virtual texturing. So the only other options is to leave each frame in memory.

[Tea Monster]

Could you enable a 'compatibility mode' which supports all the old content? If you tried to load a mod with a stupid amount of uncompressed data, a big warning will come on screen about the fact that because you are not using modern assets, you won't get the best performance. That way you can load old mods with Gigs of uncompressed data. This way it would be compatible with the old content.

Those who want the performance and want to move forward can use the new formats and have zippy loading times.

[icecoldduke]

Tea Monster, on 02 June 2016 - 05:14 PM, said:

Could you enable a 'compatibility mode' which supports all the old content? If you tried to load a mod with a stupid amount of uncompressed data, a big warning will come on screen about the fact that because you are not using modern assets, you won't get the best performance. That way you can load old mods with Gigs of uncompressed data. This way it would be compatible with the old content.

Those who want the performance and want to move forward can use the new formats and have zippy loading times.

Your describing the legacy mode I talked about earlier and Hendricks said no .

[Kyanos]

icecoldduke, on 02 June 2016 - 05:21 PM, said:

Your describing the legacy mode I talked about earlier and Hendricks said no .

Except your version had you disabling effects.

Spoiler

Maybe we just want to make Duke lag like we're rocking 28K modems

[icecoldduke]

Drek, on 02 June 2016 - 05:26 PM, said:

Except your version had you disabling effects.

Spoiler

Maybe we just want to make Duke lag like we're rocking 28K modems

That is correct my legacy version would have NG effects completely disabled. The point of legacy mode is for old mods only. Not for new content. But as I said Hendricks nix'ed the idea so it won't happen.

[Mark]

And that makes perfect sense. To keep the old maps and mods "true to the artist's original vision" all new rendering features should be disabled.

[Tea Monster]

Old mods are not designed for new renderers, they don't use normal maps, they don't use specular maps, they don't use physics. So why do people want them turned on to play them? I don't understand that.

Old mods would be played in something like the original Polymost - for which they were originally designed - explain the problem please.

EDIT: Maybe if you just turn on the pretty lights - I think that is all they really want. Turn on coloured lighting, turn off every other rendering perk. You would basically have a Quake III style renderer. Fix any skybox issues that exist in the current Polymost and I think you'd sell that to most of the users here.

Put it this way - If a year ago someone had come along and just offered them that - a fixed and fully working Polymost with lighting - they would have hailed you as the new Saviour of Dukedom.

[icecoldduke]

Tea Monster, on 02 June 2016 - 05:41 PM, said:

EDIT: Maybe if you just turn on the pretty lights - I think that is all they really want. Turn on coloured lighting, turn off every other rendering perk. You would basically have a Quake III style renderer. Fix any skybox issues that exist in the current Polymost and I think you'd sell that to most of the users here.

The legacy mode is designed to load old mods, but annoying enough so you won't use it to make new content. No lights in the legacy mode. The only advantage to loading old mods into PolymerNG is the performance boost. As I said though I would like to start a new HRP NG team to start NGing the old classic maps, is there interest here in doing that?

[Mblackwell]

icecoldduke, on 02 June 2016 - 05:50 PM, said:

The legacy mode is designed to load old mods, but annoying enough so you won't use it to make new content. No lights in the legacy mode. The only advantage to loading old mods into PolymerNG is the performance boost.

Ah so you'll break Decay in PolymerNG just because you feel like it.

[icecoldduke]

Mblackwell, on 02 June 2016 - 05:51 PM, said:

Ah so you'll break Decay in PolymerNG just because you feel like it.

Why don't we talk offline? I would like it if a couple of you including TX and myself to get on skype and flush out some of these concerns. For the record it isn't just because I feel like it, there are solid technical reasons why its a bad idea, and I don't want new mods to make bad content for PolymerNG. PolymerNG is only as good as the content you guys make, and in PolymerNG it matters how you make content.

[Kyanos]

Tea Monster, on 02 June 2016 - 05:41 PM, said:

EDIT: Maybe if you just turn on the pretty lights - I think that is all they really want. Turn on coloured lighting, turn off every other rendering perk. You would basically have a Quake III style renderer. Fix any skybox issues that exist in the current Polymost and I think you'd sell that to most of the users here.

Put it this way - If a year ago someone had come along and just offered them that - a fixed and fully working Polymost with lighting - they would have hailed you as the new Saviour of Dukedom.

Basically this, make "legacy mode" compatible with yesterdays content made for all three renderers, even if it crawls.
md3s, lights, normals, specs, glow maps...

Limit any NG effects to "proper efficient content"

[Hendricks266]

Such a distinction is arbitrary and takes choice away from the content creators. I don't care if you have an engineering superiority complex, you can't tie others' hands behind their backs.

In this case, "even if [normal mode] crawls", it will not matter for you Cataclysm guys since you won't be using egregious amounts of vertex animation anyway. Right?

[Hendricks266]

Tea Monster, on 02 June 2016 - 05:41 PM, said:

Old mods would be played in something like the original Polymost - for which they were originally designed - explain the problem please.

There is more to choice of renderer than fancy effects and modding capabilities. For example, Classic software mode struggles to scale its FPS as display resolutions outpace single-core CPU performance. Polymost destroys it in framerate (and battery life on mobile).

As another example, Polymost as it stands is not suited to supporting VR freelook.

There are more, but I hope you'll understand there is an entire category of concerns to think about.

EDIT: As another example, currently only PolymerNG runs on Xbox One.

[MusicallyInspired]

icecoldduke, on 02 June 2016 - 05:28 PM, said:

That is correct my legacy version would have NG effects completely disabled. The point of legacy mode is for old mods only. Not for new content. But as I said Hendricks nix'ed the idea so it won't happen.

Then what is the point in even using PolymerNG if all its unique effects are turned off?? We could just use Polymost or the classic renderer.

Tea Monster, on 02 June 2016 - 05:41 PM, said:

Old mods are not designed for new renderers, they don't use normal maps, they don't use specular maps, they don't use physics. So why do people want them turned on to play them? I don't understand that.

Old mods would be played in something like the original Polymost - for which they were originally designed - explain the problem please.

Any map can conceivably work with a theoretical HRPNG just as they do with the HRP in Polymer. In that case it doesn't matter if content was designed for PolymerNG or not because the HRPNG would have been.

Quote

EDIT: Maybe if you just turn on the pretty lights - I think that is all they really want. Turn on coloured lighting, turn off every other rendering perk. You would basically have a Quake III style renderer. Fix any skybox issues that exist in the current Polymost and I think you'd sell that to most of the users here.

Put it this way - If a year ago someone had come along and just offered them that - a fixed and fully working Polymost with lighting - they would have hailed you as the new Saviour of Dukedom.

No. I dislike Polymost because it has shortcomings. No TROR for instance. Polymer has a skybox limitation that needs to be addressed. The allure for me is that ideally PolymerNG would solve both of these problems and be the ideal high-res renderer to play any content developed over the years. Mods with custom models and textures and whatnot are obviously a slightly different story. Though, it depends on how much new content there is vs what would be replaced by the HRPNG.

icecoldduke, on 02 June 2016 - 05:50 PM, said:

The legacy mode is designed to load old mods, but annoying enough so you won't use it to make new content. No lights in the legacy mode. The only advantage to loading old mods into PolymerNG is the performance boost. As I said though I would like to start a new HRP NG team to start NGing the old classic maps, is there interest here in doing that?

Again I say, what performance boost? Polymost runs like the wind. There are no fallbacks other than lack of certain functionalities that Polymer includes like TROR.

icecoldduke, on 02 June 2016 - 05:53 PM, said:

For the record it isn't just because I feel like it, there are solid technical reasons why its a bad idea, and I don't want new mods to make bad content for PolymerNG. PolymerNG is only as good as the content you guys make, and in PolymerNG it matters how you make content.

Who are you to decide what is bad content? If someone wants to create "bad" content that's their decision and they should deal with the consequences and ramifications. You're like the government trying to institutionalize social laws so that people aren't allowed to offend other people. You're like an NG Content Justice Warrior! (Oops. I broke Berkley's Law, Inspector Lagomorf)

Seriously, though. Sure you can say "These are my brand new toys and you have to play with them the way I want you to" but that kind of behaviour usually just ends with the other kids deciding to play with someone else's toys.

Hendricks266, on 02 June 2016 - 06:11 PM, said:

In this case, "even if [normal mode] crawls", it will not matter for you Cataclysm guys since you won't be using egregious amounts of vertex animation anyway. Right?

I still resent the term "Cataclysm guys."

[LeoD]

icecoldduke, on 02 June 2016 - 12:58 PM, said:

This is just some of what I want to see in a HRP NG version of the original levels.

Tea Monster, on 02 June 2016 - 02:51 PM, said:

Very little of the HRP is compatible with either Polymer or PolymerNG. Virtually all of them need to be remade.

Which simply won't happen.
15 years of HRP -> still not complete, but at least very well playable for most maps (unless they come with too much custom ART). Opinions on style and consistency may vary.
7 years of Polymer -> only a fraction of the contents have been updated or remade.
PoylmerNG -> some people will come up with a couple of showcase models and textures, but in the end no one will adopt the task of [re]making all those unfancy and rarely used assets, and we will end up with the same complaints we've all heard a thousand times about the current HRP already. Or worse. And we haven't yet talked about the inevitable frustrating style and consistency discussions yet.
So my conclusion is: if PolymerNG doesn't fully support the existing Polymost/Polymer features, it will go nowhere.

MusicallyInspired, on 02 June 2016 - 06:56 PM, said:

I dislike Polymost because it has shortcomings.

But it displays Billy Boy's maps correctly.
Clearwater aka Cranium is a notable example. To be fair: I use Polymer [HRP] whenever both the frame rate and the rendering are acceptable.

[icecoldduke]

There are a lot of you that believe what I'm choosing to do is arbitrary, that is far from the truth. I have worked on many AAA games in my carrier. I have experience to back up my decisions on what I plan to do with PolymerNG.

The point of PolymerNG is to have NG rendering effects, that runs fast, and provides a great immersive experience to people on this side of the millennium gap. To do that you need to not build content in such a way that causes bottlenecks in the renderer. This is what I call...bad content; bad content is content that requires a implementation that causes GPU bottlenecks and doesn't yield significant benefit.

[Mblackwell]

And that has what to do with the conversation? There's fundamentally different engine design goals and structure, and you programmed with a single game application goal in mind. EDuke32 is more like Unity. It's not a game but a swiss army knife to make games with, and yes the choice to disable DOF if someone uses vertex animation is completely arbitrary, as is your decision to implement virtual textures and force their use in all circumstances even when it would turn an otherwise functional combination of effects and assets into a poor performer.

[icecoldduke]

Mblackwell, on 02 June 2016 - 07:35 PM, said:

And that has what to do with the conversation?

I just want to put to bed the idea that there is no logic and reason behind what I'm doing.

Mblackwell, on 02 June 2016 - 07:35 PM, said:

EDuke32 is more like Unity.

I have shipped two titles on Unity.

I want PolymerNG to succeed and to do that I need you guys to make content, properly. I also need people to help with NGing the current HRP. I understand you guys want a swiss army knife, but lets get Duke Nukem 3D NG'ed first before we expand the scope of the effort.

[LeoD]

Hendricks266, on 02 June 2016 - 10:21 AM, said:

The HRP already diverged into Polymost and Polymer versions, with no good way of switching between the two automatically. A third version is only more of the same problem.

But no showstopper. After I have put some work into it, both flavours now live in peace within the same repo.

Hendricks266, on 02 June 2016 - 10:21 AM, said:

Actually, the HRP could definitely use some limited scripting capability [...]

Things like

ifdef CONST

and

ifexist FILE

are on top of my wish list ...

[Mblackwell]

You aren't shipping titles on Unity, you are shipping Unity.