[Steveeeie]

 icecoldduke, on 03 June 2016 - 08:55 AM, said:

Please see two posts above .

Still not addressing my point, or I'm not communicating my point effectively.

[Kyanos]

 icecoldduke, on 03 June 2016 - 08:52 AM, said:

I'd like all new models to be in the FBX format(it doesn't really matter, since it just gets converted to the model payload format anyway). I'll work on getting you guys Win64(Win7/8) x64 builds this weekend.

So def edits to only use one model per frame will be fine for starters. I'll structure it like the override pack so that we'll end up with file structure like this in the /sprites/ folder.

`
monsters.def
monsters_polymerng.def
monsters_polymost.def
`

[Steveeeie]

 Drek, on 03 June 2016 - 09:07 AM, said:

So def edits to only use one model per frame will be fine for starters. I'll structure it like the override pack so that we'll end up with file structure like this in the /sprites/ folder.

`
monsters.def
monsters_polymerng.def
monsters_polymost.def
`

One model per frame is crazy.

[Hendricks266]

icecoldduke, on 03 June 2016 - 08:52 AM, said:

I'd like all new models to be in the FBX format(it doesn't really matter, since it just gets converted to the model payload format anyway).

I hate to revive the "cooked assets" discussion again but at least temporarily can we stick to loading stuff using def syntax?

icecoldduke, on 23 May 2016 - 08:36 PM, said:

In the cases were you need to add data that breaks the current format, you have code that can read in the old data and convert it to the new format.

Since we are "shipping Unity", we can't afford binary blobs like this. We have had to make small, incremental changes to our savegame/demo format dozens of times (svn blame the BYTEVERSION_JF line in the source), breaking backwards compatibility each time. If we had added code to translate between old versions, it would be a sprawling monster. Flexible structures are the way to go, and at that rate content is better served by simple human-readable text. I want to make savegames perfect-forward compatible by moving them closer to a def-like model, though probably using internal four-byte IDs and a strict binary structure.

I strongly support the use of a local cache for data into a format that only the current version of the program need understand.

[icecoldduke]

Steveeeie, on 03 June 2016 - 09:01 AM, said:

I'm with tea monster, this is because its way too tricky to make things for.

if we got a decent model format and sensible material and animation tools I would personally be all over it.

Steveeeie, on 03 June 2016 - 09:03 AM, said:

Still not addressing my point.

I would like everyone to use FBX only. As far as my official position on vertex animation for the Duke Nukem reloaded PolymerNG project(I need to come up with a better project name), we have a few options and I figure you are the best person to choose which one is best.

• Use vertex animation and keep every frame loaded in VRAM.
  
• Use lunatic for prop animation.
  
• Export each frame of the animation to have a frame per tile, Drek is going to be exporting data to try this out. I would then do a motion blur on the frame deltas.

If you have any other ideas let me know, but I figure your the best person to choose the best way forward for the Duke Nukem reloaded PolymerNG project.

[Hendricks266]

Steveeeie, on 03 June 2016 - 09:01 AM, said:

if we got a decent model format and sensible material and animation tools I would personally be all over it.

I absolutely want to tread lightly as we enter into this discussion, but I must bring this up: Would you be willing to take some direction on the assets you produce? From the beginning we need to establish some level of functional accuracy to the original material, without neutering artistic liberty.

[icecoldduke]

Hendricks266, on 03 June 2016 - 09:09 AM, said:

I hate to revive the "cooked assets" discussion again but at least temporarily can we stick to loading stuff using def syntax?

PolymerNG uses the def system, but instead of pulling the data from the .md3 or .fbx or whatever it pulls the data from the model payload cache.

Hendricks266, on 03 June 2016 - 09:09 AM, said:

Since we are "shipping Unity", we can't afford binary blobs like this.

I'll respond to this one later today(I don't have time right now to give this its due attention), but I disagree with you. .

[Kyanos]

Steveeeie, on 03 June 2016 - 09:09 AM, said:

One model per frame is crazy.

We just went over this, 6million verts per monster is crazy.

It's just temporary so all animations at least, like, animate. Then you talented modellers can breathe a little while remaking an entire game worth of content. It'll make a usable HRP with little effort on my end this weekend. I'm literally just going to go over the defs and pick the frame closest to the current sprite, instead of letting the intended animations play out. Easy Peasy the whole HRP can be used until you redo the whole HRP.

[Steveeeie]

Drek, on 03 June 2016 - 09:18 AM, said:

We just went over this, 6million verts per monster is crazy.

It's just temporary so all animations at least, like, animate. Then you talented modellers can breathe a little while remaking an entire game worth of content. It'll make a usable HRP with little effort on my end this weekend. I'm literally just going to go over the defs and pick the frame closest to the current sprite, instead of letting the intended animations play out. Easy Peasy the whole HRP can be used until you redo the whole HRP.

If we are remaking content, we want to go higher poly, which will choke and there is nothing in the current HRP that is too high poly, not by a long shot.

The only reason there are so many verts is because its storing every single frame.

[Hendricks266]

icecoldduke, on 03 June 2016 - 09:12 AM, said:

• Use vertex animation and keep every frame loaded in VRAM.

This will work fine. If we support FBX, the most expensive models at the top of the list can be the first ones that the HRP eliminates in PolymerNG mode. The MD3s can stay for compatibility with older renderers.

icecoldduke, on 03 June 2016 - 09:12 AM, said:

• Use lunatic for prop animation.

Consider this option off the table. It's using a bulldozer to dig a posthole, and the bulldozer is far from fully built.

We should support it someday as a feature for content creators, but it can't be the only option.

icecoldduke, on 03 June 2016 - 09:12 AM, said:

• Export each frame of the animation to have a frame per tile, Drek is going to be exporting data to try this out. I would then do a motion blur on the frame deltas.

We actually must support this (sans motion blur) by virtue of being a direct analogy to ART animations and CON actions. Content creators can use this if they enjoy cartoon-like jerky movements, but it is too restrictive to be the only option.

icecoldduke, on 03 June 2016 - 09:14 AM, said:

PolymerNG uses the def system, but instead of pulling the data from the .md3 or .fbx or whatever it pulls the data from the model payload cache.

This must mean that you've introduced new syntax that I may not want to support going forward (aka forever).

icecoldduke, on 03 June 2016 - 09:14 AM, said:

I'll respond to this one later today(I don't have time right now to give this its due attention), but I disagree with you. .

You can disagree with facts but they remain true. We are not making a one-and-done game.

[Steveeeie]

Hendricks266, on 03 June 2016 - 09:14 AM, said:

I absolutely want to tread lightly as we enter into this discussion, but I must bring this up: Would you be willing to take some direction on the assets you produce? From the beginning we need to establish some level of functional accuracy to the original material, without neutering artistic liberty.

Its too early to enter this kind of discussion for me, unless the engine can handle assets correctly like any other modern engine I wont be going near it, its too much hassle.

[icecoldduke]

Hendricks266, on 03 June 2016 - 09:21 AM, said:

This must mean that you've introduced new syntax that I may not want to support going forward (aka forever).

I have not touched the def files at all. I simply modified the code to look for the models in the payload cache files instead. I store a table at the header of the file that contains payload information, including the path to the model(e.g. highres/something/my_awesome_model.md3), I'll change this to a hash later on. You can drag and drop the HRP def files that are in the depot now into PolymerNG, build the offline payload cache, and run.

[Kyanos]

Steveeeie, on 03 June 2016 - 09:20 AM, said:

If we are remaking content, we want to go higher poly, which will choke and there is nothing in the current HRP that is too high poly, not by a long shot.

The only reason there are so many verts is because its storing every single frame.

Precisely, a quick edit to redifine them to only store 1 frame per tile will cut animations by up to 90% in some cases. Making the models at least display and work as-is. All the new content won't be done by Monday, this is simply so that we can see what we have to work with better.

[Mblackwell]

Just to say:
Helping with interest is a worthy goal.

But.



Modern game development and asset pipelines generally involve large groups of people working in tandem to produce even small things. So FORCING full modern everything would actually be detrimental to interest long term since you greatly increase the time investment and skill requirement.


Additionally beware distributing anything that potentially would allow a person to effectively freely distribute Duke Nukem 3D (or something close to it). If there's even a whiff it will get taken down.

[Kyanos]

icecoldduke, on 03 June 2016 - 09:12 AM, said:

Drek is going to be exporting data to try this out. I would then do a motion blur on the frame deltas.

I plan on defining 1 frame to 1 tile, from a MD3 with many frames (exactly how they sit in the HRP) then defining the next tile to a different frame in the same MD3.

Will that work? Does the engine only load the single frame I def in? Or will it load the entire model each time? You don't need a single model with a single frame per tile do you?

[icecoldduke]

Mblackwell, on 03 June 2016 - 09:49 AM, said:

Additionally beware distributing anything that potentially would allow a person to effectively freely distribute Duke Nukem 3D (or something close to it). If there's even a whiff it will get taken down.

The original data will still be required, all new content and modifications will go into map hacks. No matter how much we NG the shit out of the maps, the original game triggers, sector layouts, etc will still be in the original data.

[icecoldduke]

Drek, on 03 June 2016 - 09:55 AM, said:

I plan on defining 1 frame to 1 tile, from a MD3 with many frames (exactly how they sit in the HRP) then defining the next tile to a different frame in the same MD3.

Will that work? Does the engine only load the single frame I def in? Or will it load the entire model each time? You don't need a single model with a single frame per tile do you?

For this too work its one model, single frame, per tile. What might work instead is having a seperate text file that has each model that you want to be vertex animated. Send me over that file, I'll add functionality to the model cache build system, and we'll see how much vram this will take up.

e.g.

highres/blah/blah.md3
highres/blah/blah2.md3

and so on.

[Kyanos]

icecoldduke, on 03 June 2016 - 10:03 AM, said:

For this too work its one model, single frame, per tile. What might work instead is having a seperate text file that has each model that you want to be vertex animated. Send me over that file, I'll add functionality to the model cache build system, and we'll see how much vram this will take up.

e.g.

highres/blah/blah.md3
highres/blah/blah2.md3

and so on.

Have you even run NG with model animations on yet?

eg. highres/all/all.md3

I still doubt that it's going to be as much memory as you say, maybe the bloat here is the fact that you load entire MD3s for every tile that uses even one frame from the MD3. That would mean Duke (all 12MBs of him) gets shoved into VRAM for every tile he has. That is not the proper way to load MD3s IMO. Is that how Polymer does it?

[icecoldduke]

Drek, on 03 June 2016 - 10:14 AM, said:

Have you even run NG with model animations on yet?

eg. highres/all/all.md3

I still doubt that it's going to be as much memory as you say, maybe the bloat here is the fact that you load entire MD3s for every tile that uses even one frame from the MD3. That would mean Duke (all 12MBs of him) gets shoved into VRAM for every animation he currently has. That is not the proper way to load MD3s IMO. Is that how Polymer does it?

No polymer updates geo for each model frame change by sending new geo data down to the video card. I don't want to do that in the first phase of this project. Remember I don't want mesh data going across the bus every frame in the first phase. If we only include the props, shoving each frame into vram all at once shouldn't have that bad of a memory footprint, but in order to test that I need a list of all the props that should be vertex animated .

[Kyanos]

You can just open the HRP and see the nice neat list there. I can run a command line tool to print the files to a .txt for you.

[icecoldduke]

Drek, on 03 June 2016 - 10:24 AM, said:

You can just open the HRP and see the nice neat list there. I can run a command line tool to print the files to a .txt for you.

So can you confirm that all the props that need vertex animation are ONLY in the props folder? There are no stray models files in any other folder.

[Steveeeie]

Drek, on 03 June 2016 - 10:24 AM, said:

You can just open the HRP and see the nice neat list there. I can run a command line tool to print the files to a .txt for you.

Just noticed how ridiculously large in size my fan sprite texture is, oh dear.

[Steveeeie]

Steveeeie, on 03 June 2016 - 10:26 AM, said:

Just noticed how ridiculously large in size my fan sprite texture is, oh dear.

The actual dimensions of the texture are about right, but running it through tinypng I can get the file size down from 2.2mb to around 700k without any loss of quality.

I know its the wrong topic but do we currently run the pngs through any kind of compression? because I bet we could kill a tone of weight.

[icecoldduke]

Steveeeie, on 03 June 2016 - 10:35 AM, said:

The actual dimensions of the texture are about right, but running it through tinypng I can get the file size down from 2.2mb to around 700k without any loss of quality.

I know its the wrong topic but do we currently run the pngs through any kind of compression? because I bet we could kill a tone of weight.

The Texture Payload offline compile tool decompresses the PNG's/JPG's and runs DXT compression on them, then ZLIB compresses the blob, and puts the compressed blobs inside of the texture payload file. For all textures in the HRP I can get everything down to 298mb.

[Kyanos]

icecoldduke, on 03 June 2016 - 10:26 AM, said:

So can you confirm that all the props that need vertex animation are ONLY in the props folder? There are no stray models files in any other folder.

in sprites\ I did ctrl+f on all the defs for "anim" and it does turn up elsewhere, like projectlies and switches, I'll get a proper list in a couple hours for you.

[Danukem]

icecoldduke, on 03 June 2016 - 08:21 AM, said:

Phase 1: Let's get the PolymerNG Duke Nukem reloaded project on its feet. Just a couple maps, something to show gamasutra, and other gamedev sites. Phase 2: Go in and support the older mods with vertex animation and fix various bugs that have caused you guys nightmares over the past 10 years.

Ultimately, what you do is your call, but I believe that doing things in that order may be a mistake. The problem is that you will need to assemble a good, unpaid team to do a lot of work without actually having much to show yet. You might be able to pull it off, but it's going to be harder than you may realize.

There is an advantage of adding in support for existing models and mods right at the start and then releasing something that we can develop for. Those of us who already have a lot of content could leverage that "legacy" content while taking advantage of some of the new renderer features to make some pretty cool stuff quickly, and without the need for you to assemble a dedicated team. This would help demonstrate the capabilities of the new renderer and could actually generate excitement, making it easier for you to recruit and maintain the team you need for your remake.

If I had access to the new renderer, I would be interested in fixing up and augmenting Duke Nukem Eternity, as seen here:





By the way, I also think you may be making a mistake by sticking with the original levels and just map-hacking them. The original level geometry and scripting effects are very primitive, and piling a lot of stuff onto them is still not going to deliver a truly next gen experience.

[icecoldduke]

Trooper Dan, on 03 June 2016 - 10:41 AM, said:

By the way, I also think you may be making a mistake by sticking with the original levels and just map-hacking them.

You have some great content there. I choose the original maps because people know those maps, you see E1L1 and you instantly know what your getting. The truth of the matter is it doesn't matter to me if we use the original maps, or your content or someone elses duke hrp mods. I need content guys and some show case pieces.

The point of phase 1 is to support ONE set of content, this will allow me to focus my efforts and getting the renderer on its feet. If we went your route, we would still have to move the charectors and monsters over to skeletal animation. That won't change, the initial effort has to be done properly. So I'll let you guys figure out if you want to do the original maps or whatever; the bottom line is I need content guys, so it doesn't matter to me one which thing we choose.

[Mblackwell]

icecoldduke, on 03 June 2016 - 10:52 AM, said:

If we went your route...

Then the mod would work in PolymerNG out of the box and he could clean up the lighting and add new effects.

Edit: Also, DT is right. The original levels will have a ton of issues since the game uses textures in really odd ways since they were pixelated. The same material in two places in the same map might be two completely different things, and the way that things tile is a bit arbitrary depending on the circumstance. That's why some of the HRP (particularly polymer) content can look a bit weird.

[icecoldduke]

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

Then the mod would work in PolymerNG out of the box and he could clean up the lighting and add new effects.

And move the monsters/characters/first person stuff over to skeletal animation . But you are correct it would eas(ier). So you guys choose what set of content you want to be the phase 1 PolymerNG effort.

[Mblackwell]

icecoldduke, on 03 June 2016 - 10:57 AM, said:

And move the monsters/characters/first person stuff over to skeletal animation .

No.

Not only is that likely impossible unless they were completely re-rigged and animated but it would be unfeasible. It would be much more feasible to just add vertex animation, and not offer bad suggestions like ONE FRAME OF ANIMATION PER TILE!

Spoiler

Seriously that's pretty bad.