[Steveeeie]

icecoldduke, on 29 May 2016 - 09:33 AM, said:

I'm talking with content guys right now about getting the vertex animation exported as skeletal animation. With all vertex animations included, uncompressed, the model cache is about 2gb of data. That's just too much. Were as vertex data for all assets is about 100mb. My next step is to get skeletal animation support in, FBX support is already in, just need to export the skeletal data to the model cache and implement skeletal animation on the engine side.

What about plain old keyframe animation and morph targets, for static props they will be important.

[icecoldduke]

Steveeeie, on 30 May 2016 - 05:59 AM, said:

What about plain old keyframe animation and morph targets, for static props they will be important.

I don't know when I can do FBX morph targets. I don't have it slated at the moment.

[icecoldduke]

Some VERY simple DOF. Right now I'm experimenting with min spec features. This is not final implementation by any means, but still cool to see some post process stuff.

[Steveeeie]

icecoldduke, on 30 May 2016 - 06:35 AM, said:

I don't know when I can do FBX morph targets. I don't have it slated at the moment.

What about keyframes?

[Steveeeie]

My concern being, skeletal animations only cater for character animations and not things like the rotating fans.
https://www.youtube....bed/9gSQg1i_q2g

[Tea Monster]

Morph targets for animated critters would be amazing too. Duke snarling to camera and the Battlelord laughing as he stomps on your head.

[Steveeeie]

Tea Monster, on 31 May 2016 - 11:07 AM, said:

Morph targets for animated critters would be amazing too. Duke snarling to camera and the Battlelord laughing as he stomps on your head.

Morph targets are also useful for things like flags and stuff

[icecoldduke]

I know morph targets will be useful, I just need to get the bandwidth to do it .

I updated the latest public github with the latest P4 revision. The sky is broken in the current code. Sprite animations are disabled, This is a known issue. To fix sprite animations re-enable

void PolymerNGBoard::DrawSprites(Math::Matrix4 &viewMatrix, Math::Matrix4 &projectionMatrix, float horizang, int16_t daang)
...
//DO_TILE_ANIM(tspr->picnum, tspr->owner + 32768); to DO_TILE_ANIM(tspr->picnum, tspr->owner + 32768);

in
PolymerNG_Board.cpp

PolymerNG Public rev 265

This includes the polymost occlusion system, mesh and texture payload system, along with a bunch of other changes. Full diff is:
Polymer NG rev 265 diff.

[HiPolyBash]

You're making progress very quickly. It's going to be interesting seeing something like Duke Nukem Eternity created using PolymerNG.

[Danukem]

HiPolyBash, on 31 May 2016 - 08:48 PM, said:

You're making progress very quickly. It's going to be interesting seeing something like Duke Nukem Eternity created using PolymerNG.

I would come out of DukePlus retirement to get that particular episode working with the new renderer, since most people didn't get to play it as intended when it was released.

[HiPolyBash]

Now that'd be awesome. My ultimate pipe dream is DNF mod getting a HD makeover and/or expansion that made full use of PolymerNG.

[Tea Monster]

Hopefully, something like that would be only the beginning.

[HiPolyBash]

In an ideal scenario PolymerNG reaching an alpha state with all the base features completed would attract a group of fans to create a showcase style mod that pushed everything to the absolute limits on a smaller scale as an example of what could be done and that'd get coverage across gaming communities such as NeoGAF, Reddit and so on attracting more people to the community who are interested in creating something related to Duke in a modern renderer without fear of legal recourse by Gearcox. That's the dream anyway..

[Danukem]

HiPolyBash, on 01 June 2016 - 04:57 AM, said:

In an ideal scenario PolymerNG reaching an alpha state with all the base features completed would attract a group of fans to create a showcase style mod that pushed everything to the absolute limits on a smaller scale as an example of what could be done and that'd get coverage across gaming communities such as NeoGAF, Reddit and so on attracting more people to the community who are interested in creating something related to Duke in a modern renderer without fear of legal recourse by Gearcox. That's the dream anyway..

I'm sure that the new renderer will be put to good use. But I don't buy into this idea that there are lots of people out there hankering for more Duke Nukem, and if only there were a flashy renderer which made it look like a modern game they would flock to the community and make new content. Also, the first really good projects that have lasting value are almost certainly going to be created by the usual suspects around here -- people with a lot of Build/EDuke32 experience and true creative inspiration. Setting out with the goal of "pushing everything to the absolute limits" doesn't sound very inspiring from a creative standpoint and is likely to result in a flashy tech demo which won't hold people's attention for long.

[icecoldduke]

I think PolymerNG will bring more people over to the community; including people who have left the community and new modders as well. The build engine, is a fun engine to work with, but that gets lost on the new generation, who want awesome looking graphics. I think having xbox one support, that supports modding, will also bring more people over to community.

Build is great to make content with, but the fact os 8bit graphics are dated, and that is a turn off for a lot of people.

[MusicallyInspired]

I don't know, retro is still pretty "in" right now. Not that it isn't still somewhat of a niche, but it's not like nobody is interested. 8-bit and "8-bit-ish" games are still some big sellers and there were more than a few retro style FPS's Kickstarted in the past couple of years.

I don't really have a point, I'm just saying.

[Steveeeie]

I'm really worried about how we are going to animate static props, and I feel my question is getting skimmed over.

Again, things like fan blades will need some kind of keyframe animation and the rubber bin folding in and the barrels expanding before popping are going to need morph targets.

are these things just going to remain completely static and not animate at this time?

Steve

[icecoldduke]

Steveeeie, on 01 June 2016 - 10:32 AM, said:

I'm really worried about how we are going to animate static props, and I feel my question is getting skimmed over.

Again, things like fan blades will need some kind of keyframe animation and the rubber bin folding in and the barrels expanding before popping are going to need morph targets.

are these things just going to remain completely static and not animate at this time?

Steve

The problem is bandwidth, and what I have time to do. Vertex animation is a waste of memory; there is no way around that fact. Another thing; currently vertex animation is restricted to md3 models; I have tried baked vertex animation inside of FBX files with mixed results. With the fan model, in theory, one could export each frame to its own model to match the tile in the art file. Then override each frame of the sprite with each frame you manually exported. You really shouldn't have a bunch of frames that are animated using vertex animation.

[Mblackwell]

That would leave people with 3 or 4 frame animations. It looks silly.

[icecoldduke]

Mblackwell, on 01 June 2016 - 03:21 PM, said:

That would leave people with 3 or 4 frame animations. It looks silly.

You could just override the tile in a map hack that points to another tile. Then override the tile with your exported baked animation frames. For a fan you can get away with a small set of frames. We could even do motion blur on the fan, that should yield the same results.

[Mblackwell]

The tile numbers are hard coded to have specific things happen. A maphack to a different tile would just break it.

Additionally right now the HRP is theoretically compatible with any mod that uses vanilla assets. If you arbitrarily start assigning tile numbers outside of the original scope you lose compatibility with mods.

[Hendricks266]

icecoldduke, on 01 June 2016 - 03:26 PM, said:

You could just override the tile in a map hack that points to another tile.

<game show buzzer sound>

[icecoldduke]

Mblackwell, on 01 June 2016 - 03:44 PM, said:

The tile numbers are hard coded to have specific things happen. A maphack to a different tile would just break it.

Additionally right now the HRP is theoretically compatible with any mod that uses vanilla assets. If you arbitrarily start assigning tile numbers you lose compatibility with mods.

Hendricks266, on 01 June 2016 - 03:45 PM, said:

<game show buzzer sound>

Not if you have maphack that doesn't change the tilenum, but only changes what tilenum it actually wants to display. This wouldn't break anything code wise.

[Hendricks266]

Changing the tsprpicnum but not the picnum is irrelevant to the idea's badness. You would have to manually instrument (maphack) every map ever. Maybe you could do some sort of global replace, but at that rate why not just get animation definitions working as they should?

[Mblackwell]

icecoldduke, on 01 June 2016 - 03:45 PM, said:

Not if you have maphack that doesn't change the tilenum, but only changes what tilenum it actually wants to display. This wouldn't break anything code wise.

Yes it does.

Because the defs overwrite/conflict with those tiles if a mod uses them.

Additionally the HRP asset would no longer be properly functional in a mod that used them unless everything was modified, which is kind of unfeasible. Additionally you massively increase the number of files in the tree (and the number of files that need to be opened at run time), and eat up valuable tiles.

You'd be better off developing your own weird compressed diff method of reading back and applying the vertex animation if space is that much of a premium, since loading the entire model into memory multiple times and creating and loading a blank tile of the proper dimensions into memory for every frame isn't going to save you any memory in the end.

[icecoldduke]

Hendricks266, on 01 June 2016 - 03:47 PM, said:

Changing the tsprpicnum but not the picnum is irrelevant to the idea's badness. You would have to manually instrument (maphack) every map ever. Maybe you could do some sort of global replace, but at that rate why not just get animation definitions working as they should?

If there is another system that accomplishes the same thing, then do that. I was just offering a solution for content guys not having a enough frames available to do my "export every frame of vertex animation and override each tile to point to each exported frame" idea.

[icecoldduke]

Mblackwell, on 01 June 2016 - 03:48 PM, said:

Additionally you massively increase the number of files in the tree (and the number of files that need to be opened at run time), and eat up valuable tiles.

You shouldn't be using vertex animation that much. That's the point. You should be using skeletal animation were ever possible.

[Mblackwell]

Depends on the object.

[Kyanos]

And where it's not possible you want to redesign the wheel? Sure it's costly to render some of the requests, but you need a better solution than a model per frame.

[icecoldduke]

Drek, on 01 June 2016 - 04:03 PM, said:

Sure it's costly to render some of the requests, but you need a better solution than a model per frame.

Yes its skeletal animation . When I get physics working, you can use the physics system to animate objects. Those two solutions are going to be the preferred animation systems in PolymerNG. I'm not reinventing the wheel, I'm saying you can't use bad content design methods any more. This is to save memory and performance.

Maybe I might have a legacy mode, that will load in vertex animated objects correctly, but I will disable all NG effects if you use it. I don't want people using vertex animation in new PolymerNG mods, including any new HRP update for PolymerNG.