[icecoldduke]

** DISREGARD** ** DISREGARD**

[Kyanos]

I'll say yes to a vis compile tool. It's a no brainer IMO as it's optional if I read your post right (slow fps or pre-compile is better than just slow fps)

Anything offline to speed up load times and rendering will probably be welcomed by mappers, then your new limits will get pushed too far

[icecoldduke]

** DISREGARD** ** DISREGARD**

[Daedolon]

icecoldduke, on 26 May 2016 - 03:47 AM, said:

Would you guys be ok with, while you guys are making maps with SOS, using the slow vis pass, and then before you release your maps you use the offline compile tool to prebuild vis.

I would like to point out that there isn't a map without SOS. If you build for Duke 3D, SOS is an integral part of the gameplay and level design, you won't find too many levels without it.

[oasiz]

I trust you know your end but just a FYI on how unpredictable movement can be.
This was achieved by glitching a door. No way You'd first think of a possible outcome like this

Not that it matters in this case since it's an obvious bug but you never know if something relies on weird side-effect like this.

[icecoldduke]

** DISREGARD** ** DISREGARD**

[MusicallyInspired]

If I'm understanding this correctly, the (offline) vis tool is for lighting, right? Can point/spotlights in Polymer be moved via a moving sector/conveyor belt? Can they be dynamic like that? I feel like I've asked this before but I don't remember the response and I'm not in a position to test that right now.

A vis tool would get a lot of use. Especially for things like the HRP. That's a fair trade-off to preserve key Build features like SOS. How would that work? You just run the tool on the map and it makes a new file with vis information? Or would it be compiled into a new standalone map format with the additional information or whatever?

[icecoldduke]

** DISREGARD** ** DISREGARD**

[Kyanos]

idear;

instead of a vis tool, vis helper flags or sprites to be added to maps (or maphacks for old maps)

I think it was hammer that had all sorts of vis helper data in the map editor

[icecoldduke]

** DISREGARD** ** DISREGARD**

[MusicallyInspired]

To make you do more work?

Seriously, though. How about both? Perhaps it could be a fallback case for certain scenarios where SOS "bugs" are taken advantage of on purpose? Just to ensure things work as the mapper intends? Does that make any sense?

icecoldduke, on 26 May 2016 - 05:28 AM, said:

No the vis tool is for figuring out what sectors are visible from any location in the map.

My mistake. I haven't done much mapping at all outside of Build with real 3D editors like Hammer/Worldcraft/UnrealEd or whatever. I'm actually fine with all dynamic lights.

[Tea Monster]

I could live with a pre-vis tool to keep compatibility.

[icecoldduke]

** DISREGARD** ** DISREGARD**

[HiPolyBash]

[Hendricks266]

icecoldduke, on 26 May 2016 - 03:47 AM, said:

A lot of people have been liking the posts I make about the offline compile tool, and I want to clarify that. Would you guys be ok with, while you guys are making maps with SOS, using the slow vis pass, and then before you release your maps you use the offline compile tool to prebuild vis. This would allow 60fps with SOS.

You and your offline tools, man. Do it on level load.

icecoldduke, on 26 May 2016 - 04:40 AM, said:

TX or Hendricks, I know con scripts can move sectors. Can we scan over the con scripts in such a way that we can deterministically figure out what sectors the mapper wants to move and which ones are static?

Sure, if you can solve the halting problem.

(So it's clear: No. It may be possible to determine some of them, and gradually catch more as you put more work into a single-state assignment disassembling framework for CON, but you will never catch all of them. The renderer has to be able to react dynamically.)

[icecoldduke]

** DISREGARD** ** DISREGARD**

[Hendricks266]

icecoldduke, on 26 May 2016 - 07:44 AM, said:

As far as dealing with the halting problem, just force execute all the triggers in the map and watch what happens.

Scripting can be triggered by anything and can do anything. You're asking for "content guys" to do the renderer's job.

[icecoldduke]

** DISREGARD** ** DISREGARD**

[Hendricks266]

20 years of content broken in PolymerNG.

Departure from the BUILD model.

[icecoldduke]

** DISREGARD** ** DISREGARD**

[MusicallyInspired]

To be clear, I consider the offline tool and/or new SE tags for flagging dynamic sectors as an acceptable compromise. But just barely. I don't know everything about rendering engines, but it just seems to me to be a little sloppy if it just cannot inherently do what the original engine does perfectly without such drastic slowdowns. I understand they are two completely different styles of doing things that true 3D space was not made for but 2.5D can get away with, but the goal really should be to preserve everything Build does and not make compromises at all. Everything should just work without extra work on the players'/content developer's part. Again, I know I'm probably coming off as a complete outsider who doesn't understand what he's talking about or what's involved, I really do. But to me it's barely worth it at all if the identity of Build changes so drastically.

I'm reminded of a similar (yet not near as crucial or important as something like Build's renderer) situation in the Monkey Island games. In Monkey Island there's a character called Stan. He's a salesman and tries to sucker you into buying products of terrible quality. In Monkey Island 1, 2, and 3 he wears this jacket with a checker pattern and when he talks he flails his arms around while the pattern remains stationary. This was due to technical limitations but became a running gag through the series. When Monkey Island 4 came out (in a 3D engine this time) they lost the effect and just had the checker pattern as a simple texture for his model. Then Telltale made Tales of Monkey Island and when they made the Stan character they went through all the work to create a custom shader so that his jacket pattern would remain stationary no matter how he was animated or which angle the camera was pointing at it. It's interesting that modern technology can't do some things nearly as simply as older technology can.




Sometimes the work is just worth it. Now this was not a very good example or comparison here and wasn't nearly as much work to replicate, but the principle is the same and the developers for Tales didn't have to do it. It goes a long way and if you're going to tackle making a new renderer for Duke3D and the Build engine in general you've got to be prepared to take on the load of recreating effectively everything that came with it. Sometimes it just seems like you're so eager to make compromises and tradeoffs at times when it simply is not acceptable. How you're coming off is most of the problem here. If you want to make a next gen Build renderer, make a next gen BUILD renderer and do it right. It's a lot of work, but that's why no one besides Plagman has even attempted it. As far as I'm concerned, if you're not willing to do everything it takes, I'm happy to leave it as is. That's not meant to be harsh it's simply the way I see things.

And no, I don't think all tradeoffs are worth it just to get Duke modding into a next gen engine. Not in any way.

[Kyanos]

icecoldduke, on 26 May 2016 - 05:44 AM, said:

While possibly doable, is there a reason you wouldn't want a automated tool to figure out visibility for you?

No, I was just throwing an idea out there. I thought it may be easier, but I assume a vis tool would be pretty much already written, you'd just need to factor it out to stand alone.

Hendricks266, on 26 May 2016 - 08:01 AM, said:

20 years of content broken in PolymerNG.

Departure from the BUILD model.

or
20 years of content finally working with Polymer Dynamic Lights at steady fps.

optimization of Polymer at the base level, maps.

[icecoldduke]

MusicallyInspired, on 26 May 2016 - 08:26 AM, said:

To be clear, I consider the offline tool and/or new SE tags for flagging dynamic sectors as an acceptable compromise. But just barely. I don't know everything about rendering engines, but it just seems to me to be a little sloppy if it just cannot inherently do what the original engine does perfectly without such drastic slowdowns. I understand they are two completely different styles of doing things that true 3D space was not made for but 2.5D can get away with, but the goal really should be to preserve everything

I'm using clcoast as a example for the worst case scenerio. I've had a few of you e-mail me your maps and say you get worst performance in Polymer with your maps compared to clcoast, clcoast is the only heavy map I have profiled, so were going to go with that. We have established on a high machine in my worst case spot in clcoast, to render only the geometry takes 13ms(72fps) in polymer. You can easily look at that and go "well thats good enough, why can't PolymerNG do that?", well PolymerNG can as well if all you want is geo only.

The point of PolymerNG is to add next generation graphical effects to the engine, and doing so that 13 milliseconds to render only the geometry is just too slow. With my optimizations that hurt SOS, I now get 4ms in that same map. I have fixed some of the CPU hits today. 4ms leaves a lot more room to do various rendering effects, then 13 ms does.The only options I have at that moment are to do things that you guys might not like, but if its passes as acceptable comprimise, even if barely, then its the best way to move forward.

So everyone here understands lets look at the break down of new rendering effects. Ms = Milliseconds. 16ms = 60fps 30ms = 30fps.

PolymerNG fast vis geometry only pass(albedo) = 4ms
---------- FUTURE ADVANCEMENTS ------------
Shadows for 5-6 shadow casting lights = 4ms - 5ms.
Lighting pass = 2-3ms.
Anti aliasing = 1ms - 2ms depending on what method I choose to do.
Tone mapping = 1-2ms.
Right now we are already at 12ms - 15ms, without Skeletal Assets, VLS, etc etc.

So to add VLS to your map in this case for example, which would take 4-5 ms, you would bneed to cut down on lighting, and geometry complexity. The margins here aren't great now lets look at if we have SOS.
PolymerNG slow vis geometry only pass(albedo) = 13ms
---------- FUTURE ADVANCEMENTS ------------
Shadows for 5-6 shadow casting lights = 4ms - 5ms.
Lighting pass = 2-3ms.
Anti aliasing = 1ms - 2ms depending on what method I choose to do.
Tone mapping = 1-2ms.
Right now we are already at 21ms - 25ms.

This is hovering around 38fps, without Skeletal Assets, VLS, etc etc.

[Jblade]

icecoldduke, on 26 May 2016 - 08:01 AM, said:

No were asking content to do contents job

you dont quite understand that you're not working with paid people do you

[Kyanos]

Quote

PolymerNG fast vis geometry only pass(albedo) = 4ms

This isn't really an option, unless it's something you can set per map knowing there is no SOS.

[MusicallyInspired]

I don't agree at all that performance trumps staple features, but that's the great thing about opinions.

[Tea Monster]

Getting anything to work with polymer will be a plus. It's unusable in it's current state. I'm not just talking about framerate either.

[Kyanos]

Jblade, on 26 May 2016 - 09:09 AM, said:

you dont quite understand that you're not working with paid people do you

He's paying content guys with a new Renderer, bartering in the 21st century

[icecoldduke]

** DISREGARD** ** DISREGARD**

[Spiker]

If I understand right even without good solution at the moment classic maps will still run fine with ror because they aren't overloaded with content and still will run much faster than Polymer.