[Kyanos]

I get that the current HRP is overkill with MD3 animations weighing far too much compared to skeletons. So much content is already made why not just say "use skeletons whenever possible for best performance" and leave it at that. I can't understand why you are so quick to cut things that are key components to older content, sure it 'should' be more efficient, but the fact is a lot of stuff was made that isn't efficient.

[icecoldduke]

Drek, on 02 June 2016 - 09:39 AM, said:

I get that the current HRP is overkill with MD3 animations weighing far too much compared to skeletons. So much content is already made why not just say "use skeletons whenever possible for best performance" and leave it at that. I can't understand why you are so quick to cut things that are key components to older content, sure it 'should' be more efficient, but the fact is a lot of stuff was made that isn't efficient.

Then I would like someone to go into the current HRP and find the assets that you guys want to be vertex animated. Then let's talk about those specific cases. Right now we aren't talking about anything specific. You guys brought up the fan animations, the fan blade rotation could be scripted, this wouldn't be an issues. The other item someone brought up was the exploding canisters. This can be handled in other ways then morph animations. You could get away with a bunch of particle effects. Even animated alpha textures. The geo doesn't actually have to implode, this seems like something you could easily fake.

[Mblackwell]

How are you going to script this rotation?
How are you going to keep the HRP compatible with Polymost and Polymer?
How will you guarantee compatibility with mods that use the HRP?
How are you going to track down all of the people that have made the content over decades and get them to update everything to match your whims?

[icecoldduke]

Mblackwell, on 02 June 2016 - 10:03 AM, said:

How are you going to script this rotation?
How are you going to keep the HRP compatible with Polymost and Polymer?
How will you guarantee compatibility with mods that use the HRP?
How are you going to track down all of the people that have made the content over decades and get them to update everything to match your whims?

• Maybe we can hi-jack lunatic for per-tile scripting that works across levels? This would allow for scripted geo animation, and you wouldn't have to do this for each level that uses the data.
  
• If you make content for PolymerNG, which means your looking to make NG content, do you want that content to work in the older renderers?

[Danukem]

Why not just allow vertex animation, and if there is too much of it make the vertex animated models render as magenta or throw up a warning about it so that devs can see where the bottleneck is coming from? I'm pretty sure the guys who are all fired up about the HRP in PolymerNG will be happy to go back and replace some models so they use skeletal animation instead to increase performance.

As someone who wants to use the new renderer for projects that use only a small number of models, it's frustrating to hear that their functionality could be limited in the name of optimizing performance in the HRP (which I don't even use).

[Kyanos]

icecoldduke, on 02 June 2016 - 09:45 AM, said:

Then I would like someone to go into the current HRP and find the assets that you guys want to be vertex animated. Then let's talk about those specific cases.

I would expect that most of the enemies in the HRP can be skeletized easily because people are here with the source files (most probably have skeletons set up already) but I think weapons and the atomic health would be good examples.

My point isn't really about the HRP, you're asking for re-animation of all models ever made for EDuke32, easily thousands of frames of vertex animation between just a few mods and tcs that use models. That stuff won't be 10MB md3s like the cycloid emperor in the HRP right now, it won't kill framerate to allow vertex animation. It will only kill framerate if we continue to misuse it as it has been.

[Hendricks266]

Mblackwell, on 02 June 2016 - 10:03 AM, said:

How are you going to keep the HRP compatible with Polymost and Polymer?

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.

icecoldduke, on 02 June 2016 - 10:09 AM, said:

Maybe we can hi-jack lunatic for per-tile scripting that works across levels? This would allow for scripted geo animation, and you wouldn't have to do this for each level that uses the data.

Actually, the HRP could definitely use some limited scripting capability for things like vweap, but CON will never be modular enough for the task. Lua can be, but Lunatic needs work.

[Kyanos]

icecoldduke, on 02 June 2016 - 10:09 AM, said:

If you make content for PolymerNG, which means your looking to make NG content, do you want that content to work in the older renderers?

If old content was made for the old renderers I want it to work with yours. That is the point, we don't expect software mode to display models, and we won't expect the older polymodes to use skeletons.

We do expect you to support simple vertex animation so that a decade worth of content can be used in your renderer.

[MusicallyInspired]

The more I read the more it seems like you're trying to just create your own NG engine on top of Build while ignoring its features entirely by replacing them. I don't think compatibility is something you care about, is it? I think you overestimate people's willingness to compromise Build engine features just for fancy NG effects.

[Danukem]

MusicallyInspired, on 02 June 2016 - 10:37 AM, said:

The more I read the more it seems like you're trying to just create your own NG engine on top of Build while ignoring its features entirely by replacing them. I don't think compatibility is something you care about, is it? I think you overestimate people's willingness to compromise Build engine features just for fancy NG effects.

That's a little unfair. Model support isn't a Build engine feature. Build did support voxels -- but notice that the original Polymer does not support them, and I don't recall Plagman being excoriated for that in this way. Drek's post right above yours is on point, though.

[MusicallyInspired]

Plagman didn't sacrifice nearly as much as what ICD is prepared to do if some of us don't speak out. Also, I'm not reaming him out or anything. And I know very little of rendering engines. I'm just posting my impressions and speaking about what concerns me as a user.

Also, voxels weren't a feature of vanilla Duke Nukem 3D and most people don't even use them.

[Steveeeie]

I still think the whole animations thing is a MASSIVE oversight on this project.

The current way it works with each frame of the animation being stored is pretty terrible so I do not support it staying this way.

What is being proposed however is also not how any other modern engine tools support animations and is not a better solution.

[Tea Monster]

MusicallyInspired - have you actually used Polymer to try and make a mod? Don't promote it till you've tried it.

That "Decade worth of content" that everyone is bitching about is designed to work with Polymost, not even Polymer, let alone PolymerNG. Putting it into NG will make it look like crap. It will look like half the HRP models that were designed for Polymost that look like freaking Christmas tree ornaments in Polymer. We shouldn't be supporting that.

What you guys are asking for is to have NG crippled so that it can work with a lot of ancient content that was never designed to work with that kind of renderer. No no no. 95% of mod content needs to be completely remade for a modern engine. It was not designed to work with a modern renderer. It was designed without using any features of a modern engine. You already have an engine that works fine with that. It's called Polymost. Use that for any Quake II/III era content.

That is NOT what PolymerNG is for. NG is a renderer specifically created to make mods that sit this side of the Millennial divide. Normal maps, metallicity, HDR lighting, physics - THAT is what it NG is about what it should be aimed at. That is it's purpose and reason for being.

Old School content - old school renderer.

Next-Gen content - next gen renderer.

[Steveeeie]

The other thing is one type of animation wont always be ideal for one mesh for example my current fan animation has a rotating blade and a bouncing chain.

If I was using UE4 I would import these as separate meshes, group them (blueprint) and set events on the group such as 'onLevelLoad', 'onDamage', etc and then I would individually specify what happens to each mesh in the group when the event is triggered, so one part might transform(scale, rotate, move) and another may morph or just do nothing at all.

Yeah its a lot of work, but its pretty much what is needed to get basic mesh animation completed in a sensible way.

More is required to push the engine forward than just pretty post process effects and ambient occlusion.

[Mblackwell]

Tea Monster, on 02 June 2016 - 11:38 AM, said:

MusicallyInspired - have you actually used Polymer to try and make a mod? Don't promote it till you've tried it.

For me - two released so far, and a few others in the pipe. Additionally "legacy" content all looked and worked properly in Polymer (but enhanced), and in Decay everything still looked and worked properly in Polymost, minus the lighting.

Quote

physics

You don't know what you're talking about here.

[Spiker]

There is not a single reason to have more than one HRP pack if this turns out as ICD says. Because PolymerNG should be better both quality and performance-wise making other packs not even worth keeping on HD not to mention they will just look bad.

Of course you can use legacy content and legacy renderers, noone forbids you doing that.

[TerminX]

Goddammit Justin, you were supposed to text me before saying ridiculous shit and starting a shitstorm.

[Kyanos]

Tea Monster, on 02 June 2016 - 11:38 AM, said:

What you guys are asking for is to have NG crippled so that it can work with a lot of ancient content

It won't hurt the NG content to have the renderer compatible with MD3s. Yes they are stupid, yes the switch should have been done years ago, yes yes yes, but...

Quote

You already have an engine that works fine with that. It's called Polymost.

You're right there, I've always preferred Polymost anyways.

I'll check back in when I can actually test NG and see some physics in build. Sounds like an interesting mod.

[Tea Monster]

MBlackwell - Are you using next-gen content? I don't know how you've done it as any kind of next-gen content in Polymer is broken

[Mblackwell]

Decay uses glow maps, normal maps, specular maps, and parallax displacement mapping.

A bug is a bug and should be fixed. Don't throw the baby out with the bathwater because of it.

[MusicallyInspired]

Putting the argument for a decade's worth of content aside, one thing remains true: it must be compatible with vanilla Duke3D in every aspect. None of this legacy nonsense that disables the very effects that would be the whole purpose of using PolymerNG. I don't make a lot of content but I do play Polymer exclusively and most of what I play is just the vanilla game with the HRP. Even the custom maps I play I'll play with Polymer. A lot of other users will do the same. It's not just new content people want to play with, there's a certain novelty attraction in playing old stuff with new paint. I'm certainly a sucker for it. This isn't just for content developers, it's for the gamers too. If PolymerNG's goal is to simply support modern mod content made with modern developer conventions that breaks old school content, I won't have much use for it...maybe that's ok. Maybe this is just not for me. But I would be immensely sad if vanilla wouldn't be 100% compatible in all its features. For the animation/fan issue, that's kind of important for an ideal "HRPNG" and skimping out by having separate models for each frame of animation (what is it like 3 frames?) is just not what I want to see in a NG renderer. If I wanted to see a 3-frame animated fan I'd use the classic renderer.

[icecoldduke]

MusicallyInspired, on 02 June 2016 - 12:49 PM, said:

Putting the argument for a decade's worth of content aside, one thing remains true: it must be compatible with vanilla Duke3D in every aspect. None of this legacy nonsense that disables the very effects that would be the whole purpose of using PolymerNG. I don't make a lot of content but I do play Polymer exclusively and most of what I play is just the vanilla game with the HRP. Even the custom maps I play I'll play with Polymer. A lot of other users will do the same. It's not just new content people want to play with, there's a certain novelty attraction in playing old stuff with new paint. I'm certainly a sucker for it. This isn't just for content developers, it's for the gamers too. If PolymerNG's goal is to simply support modern mod content made with modern developer conventions that breaks old school content, I won't have much use for it...maybe that's ok. Maybe this is just not for me. But I would be immensely sad if vanilla wouldn't be 100% compatible in all its features. For the animation/fan issue, that's kind of important for an ideal "HRPNG" and skimping out by having separate models for each frame of animation (what is it like 3 frames?) is just not what I want to see in a NG renderer. If I wanted to see a 3-frame animated fan I'd use the classic renderer.

I would like to see a HRP NG versions of the original levels, updated models and such. This is part of the "new content" I keep talking about. You take the original levels as they are, for example the first part in E1L1 after you fall from the vent. Picture the street with screen space reflection, rain falling down, the CINEMA sign with HDR glow and the lights on the MILLION DOLLAR texture move a like vegas animated lights, also with HDR glow. Then picture the fire in the dumpster with smoke coming off of it. And much more.

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

[Steveeeie]

MusicallyInspired, on 02 June 2016 - 12:49 PM, said:

Putting the argument for a decade's worth of content aside, one thing remains true: it must be compatible with vanilla Duke3D in every aspect. None of this legacy nonsense that disables the very effects that would be the whole purpose of using PolymerNG. I don't make a lot of content but I do play Polymer exclusively and most of what I play is just the vanilla game with the HRP. Even the custom maps I play I'll play with Polymer. A lot of other users will do the same. It's not just new content people want to play with, there's a certain novelty attraction in playing old stuff with new paint. I'm certainly a sucker for it. This isn't just for content developers, it's for the gamers too. If PolymerNG's goal is to simply support modern mod content made with modern developer conventions that breaks old school content, I won't have much use for it...maybe that's ok. Maybe this is just not for me. But I would be immensely sad if vanilla wouldn't be 100% compatible in all its features. For the animation/fan issue, that's kind of important for an ideal "HRPNG" and skimping out by having separate models for each frame of animation (what is it like 3 frames?) is just not what I want to see in a NG renderer. If I wanted to see a 3-frame animated fan I'd use the classic renderer.

Pretty much sums up my opinion on the subject.

I really just want a good platform to build a decent next gen content pack on top of for the original game.

[Steveeeie]

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

I would like to see a HRP NG versions of the original levels, updated models and such. This is part of the "new content" I keep talking about. You take the original levels as they are, for example the first part in E1L1 after you fall from the vent. Picture the street with screen space reflection, rain falling down, the CINEMA sign with HDR glow and the lights on the MILLION DOLLAR texture move a like vegas animated lights, also with HDR glow. Then picture the fire in the dumpster with smoke coming off of it. And much more.

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

This is all pipe dream thinking in comparison to basic animation support.

[icecoldduke]

Steveeeie, on 02 June 2016 - 12:59 PM, said:

This is all pipe dream thinking in comparison to basic animation support.

Not if we can find some content developers to do it. In my mind PolymerNG is going to be for NG content. I'm going to have to support everything I do when it's complete and I can forsee a bunch of support issues with vertex animation. I don't see any good coming from it, which is why I'm against having vertex animation support. I know artists like it, but it's a engineering nightmare. My goal with PolymerNG is to make a high performance renderer, you guys know this, and I need content guys that are willing to make next gen content to replace the current HRP for PolymerNG to fully take advantage of the renderer.

You guys complain about performance all the time. Look up how many topics on this forum are complaining about Polymer and Polymost performance. The solutions I'm purposing help allieviate a huge concern that you guys have posted about for long time.

TerminX, on 02 June 2016 - 12:15 PM, said:

Goddammit Justin, you were supposed to text me before saying ridiculous shit and starting a shitstorm.

I didn't know everyone was going to be so attached to vertex animation . It's not a build feature and most NG engine's don't support it. If I say I will support morph targets in the future can you guys live with that?

I would also like to get a NG HRP team started, I know one person is currently helping out with that. Is there anyone else right now that would interested in joining?

[TerminX]

If you don't support vertex animation, that means you don't support md3, which means you don't support a single model in the HRP now or in any other existing content. That's unacceptable.

How exactly are you implementing things that causes vertex animation to be a performance hit? Rendering models is very fast in Polymer currently. We're talking about a nearly 20 year old model format here. What is the problem?

[icecoldduke]

TerminX, on 02 June 2016 - 02:39 PM, said:

If you don't support vertex animation, that means you don't support md3, which means you don't support a single model in the HRP now or in any other existing content. That's unacceptable.

How exactly are you implementing things that causes vertex animation to be a performance hit? Rendering models is very fast in Polymer currently. We're talking about a nearly 20 year old model format here. What is the problem?

The models that have vertex animation are too high poly, and take up too much space(2gb of vram ready data). I have two options, waste vram and leave each frame resident in video memory, or update each model each frame. I don't like either option.

Monsters, player model, and first person weapons have to be swithed over to skeletal animation. Those are just high poly to stay vertex animated. Props if they are low poly can possibly stay but I would like those eval'ed on a case by case basis. If those stay vertex animated I would like to have each frame resident in memory. I don't want a bunch of data going across the bus each frame.

[Tea Monster]

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

[HiPolyBash]

Real talk: the majority of the HRP is a mishmash of different art styles that come together and look like complete shit over all. There are some fantastic assets in there for sure (Devastator comes to mind) but the majority of it is outdated or conflicting as far as style and quality go. PolymerNG should preferably be available under EDuke32 as an option similarly to how Polymer/Polymost are now so people have options in the case that certain content works better under the older renderers performance or compatibility wise. Having said that I don't understand how difficult it can be to have rudimentary .MD3 support in the renderer so that at the very least Duke Plus, Decay, and other mods that take advantage of models can work out of the box.

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.

The other thing is that you need to realize modders and content creators are going to push this thing as far as it'll go. Optimize the core features as much as you can for sure but allow people to circumvent any arbitrary limitations and avoid being nagged if their goal is to push everything as far as it'll go. Scalability and options are at the core of PC gaming and modding communities, have a set of guidelines to follow and let the renderer tell content creators if they're bottlenecking performance in one way or another so that they can optimize what they're working on but in no way should this ever limit people from what they want to do. It's all up to the content creators and how they want to make use of the engine, the best you can do is optimize the renderer as much as you can, release a set of guidelines to follow for optimal performance, and implement a system that'll allow content creators to narrow down where the biggest performance impact is coming from.

Encourage content creators to optimize their content but don't sacrifice support for mods that make use of these older formats. Active community members will likely go back and update their mods to take advantage of your renderer but in the mean time butchering compatibility in the name of performance goals isn't the solution especially when the majority of current content runs without a hitch.

[icecoldduke]

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.

The model format isn't the issue. It's vertexdata x numvertexes x numframes = huge amount of data. Initially I wasn't going to ditch vertex animation, but your assets are too high poly to support vertex animation. Polymer and Polymost upload frame updates on the fly, which taxes the bus on your motherboard. This conflicts with me implementing virtual texturing for example, since I need to transfer data from main ram to vram, which uses the bus.

There is no magic Polymost fix for this. I don't want model data going from main ram -> vram, per animated asset in view, per frame change. So the only option I have is to leave each frame resident in vram, which means you will need a 3gb+ card to run PolymerNG with all the current vertex animated objects.

Your guys's stuff is too high poly.