[Danukem]

Hendricks266, on 23 March 2018 - 02:46 PM, said:

Let the lesson be to always design your shading in Classic. For fixing existing maps, it is possible that an m32script can be designed to make quick work of the task.

Sure, if it's a simple linear change, like changing all shade or visibility values by certain numbers. But if it's more complicated than that, then it will prove problematic.

I'm interested to hear what Gambini will say about the classic shading rule. To my knowledge, he has always cared about how maps looked in classic and I find it hard to believe that he had not paid attention to that when designing those maps.

[Gambini]

Sure. The problem is that since i have been using models, i run only polymost with r_usetileshades 2 and those shading parameters i posted as my autoexec.cfg.

There is sadly no such thing as a magic mapster32 script which may adjust all parameters involved on restoring what i have achieved after a lot of fine tuning. i doubt anyone would tinker with them unless they have at least a rough idea of what they are doing. So I don´t see no reason for them being locked.

Quote

Let the lesson be to always design your shading in Classic. For fixing existing maps, it is possible that an m32script can be designed to make quick work of the task.

There´s no lesson here because at the time i built the largest part of those maps, those parameters were of free use. Also, when you design a map for polymost, you can´t map on classic because many things dont work like models, skyboxes, etc.

Can you confirm r_usenewshading, r_usetileshades and r_shadescale commands are locked on the console? Is there a way I can ship a mod which overrides the default values?

[Forge]

Is it because the port is being used for a commercial game, so now everything has to be locked up ala DNF 2011?

[Danukem]

Gambini, on 24 March 2018 - 07:58 AM, said:

Sure. The problem is that since i have been using models, i run only polymost with r_usetileshades 2 and those shading parameters i posted as my autoexec.cfg.

There is sadly no such thing as a magic mapster32 script which may adjust all parameters involved on restoring what i have achieved after a lot of fine tuning.

Your fine tuning would stay largely intact. The idea is that we figure out a formula that when applied to the current maps, makes the shading and visibility on them look correct in the current Polymost build. The changes between builds surely weren't random, there must have been some rules that were followed governing the changes; therefore it seems reasonable to assume that a script which globally changes shade and visibility settings according to a reverse-engineered formula could at least closely approximate what is needed to make the maps look correct. If you were to, say, fix a small area in one map, and you noticed a pattern in the changes you were making, I could probably make a script that applied that pattern of changes globally. At that point we test it out -- probably it will be wrong in certain ways for other map areas. Then we make some adjustments and try an improved formula. The whole process would probably take a few hours before it was correct, but it would still be a fraction of the time needed to redo all the maps.

Forge, on 24 March 2018 - 08:16 AM, said:

Is it because the port is being used for a commercial game, so now everything has to be locked up ala DNF 2011?

Very unlikely. Ion Maiden evidently uses a somewhat different build where various things work differently (e.g. you have to hold shift and ~ to open the console), so if there was anything they wanted to lock up, it would make sense to do so only on the IM branch.

[Phredreeke]

Not to mention... eduke32 is open source, anything done to "lock it down" could be undone in the source code.

[Forge]

Then why remove tools that used to be openly available to mappers and modders?

[Gambini]

That is not an option. Even if i could compile my own version with the commands re-enabled, it would have to distribute a non official branch of the port solely for that purpose.

It is already difficult enough to make people understand they should play the released version of our mod using the build we provided back then, go figure making people use a standalone version of the port, just because this.

[Fox]

Gambini, you based the results on an unfinished renderer. The purpose has always been to have Polymost and Polymer look more like classic mode.

Gambini, on 23 March 2018 - 01:03 PM, said:

Visibility has changed drastically and console commands like r_usetileshades, r_shadescale, r_usenewshading don´t do anything when entered on the console.

Does it works if you turn off palette emulation (Options -> Display Setup -> Polymost Setup)? A shader has been on work for GL, so some of the older features may not work in the most recent build.

Gambini, on 23 March 2018 - 01:03 PM, said:

And this is how it looks now on 6788, almost like before but now with a parallax glitch (notice the vertical strips of misalligned sky above the buildings on the distance)

The sectors with parallaxed ceilings use different pannings. Recently we fixed the panning in Polymost mode.

Type this in Mapster console to fix the panning of all skies:

do gamevar i 0 0
do for i allsectors { ifand sector[i].ceilingstat 1 { set sector[i].ceilingxpanning 0 set sector[i].ceilingypanning 0 ifand sector[i].floorstat 1 { set sector[i].floorxpanning 0 set sector[i].floorypanning 0 } }

It would also be possible to do so via CON, if you are interested.

Gambini, on 23 March 2018 - 01:03 PM, said:

This is what both autoexec.cfg and m32_autoexec.cfg read, at least the r_usetileshades command seems to work on the autoexec for Eduke32:

r_shadescale 0.65
r_usenewshading 2
r_novoxmips 1
r_usetileshades 2

While you could fix the shading via Mapster script / CON, it may cause issues with secotor effectors and such. So I recommend a custom shade table with 48 shades to get a result similar to 0.65.

[Hendricks266]

Gambini, on 24 March 2018 - 07:58 AM, said:

There´s no lesson here because at the time i built the largest part of those maps, those parameters were of free use. Also, when you design a map for polymost, you can´t map on classic because many things dont work like models, skyboxes, etc.

Can you confirm r_usenewshading, r_usetileshades and r_shadescale commands are locked on the console? Is there a way I can ship a mod which overrides the default values?

I said nothing about them being locked. I said you are wrong to use them. They are for users, not for mod authors.

[Danukem]

Fox, on 24 March 2018 - 10:56 AM, said:

Gambini, you based the results on an unfinished renderer. The purpose has always been to have Polymost and Polymer look more like classic mode.

You have been very helpful, and I will try to work with you and Gambini on implementing the suggestions in your post. However, I wish that you guys (meaning the developers) would show more respect to mappers like Gambini and think about your choice of words. Polymost has been the renderer of choice for most players and mappers for over a dozen years now. Simply saying it's an "unfinished renderer" and that maps shouldn't be calibrated to it will come as a surprise to most people, but more importantly it doesn't acknowledge the tremendous amount of work that has gone into making content for it over the years. I'm not suggesting that what you say is factually incorrect, by the way, but I am saying that this comment you make here and various other comments by Hendricks266 from time to time come off as dismissive and needlessly disrespectful.

Fox, on 24 March 2018 - 10:56 AM, said:

Does it works if you turn off palette emulation (Options -> Display Setup -> Polymost Setup)? A shader has been on work for GL, so some of the older features may not work in the most recent build.

Will check

Fox, on 24 March 2018 - 10:56 AM, said:

Type this in Mapster console to fix the panning of all skies:

do gamevar i 0 0
do for i allsectors { ifand sector[i].ceilingstat 1 { set sector[i].ceilingxpanning 0 set sector[i].ceilingypanning 0 ifand sector[i].floorstat 1 { set sector[i].floorxpanning 0 set sector[i].floorypanning 0 } }

Will do.

Fox, on 24 March 2018 - 10:56 AM, said:

I recommend a custom shade table with 48 shades to get a result similar to 0.65.

Sounds good, but I don't know how to do that and I don't think Gambini does either

[Fox]

Does this TC uses the same base palette?

[Danukem]

Fox, on 24 March 2018 - 12:23 PM, said:

Does this TC uses the same base palette?

Yes, it uses the standard Duke 3D palette.

[Gambini]

nope, we use Lezing´s Extclut palette.

Will look at those things later, now i am on a rush.

[Fox]

I meant the base palette, not the lookups.

[Gambini]

Not sure what you mean, I only added the ExtClut thing.

BTW the palette emulation thing is locked on polymost setup, but i have no idea what it does.

[Danukem]

Gambini, on 24 March 2018 - 03:06 PM, said:

BTW the palette emulation thing is locked on polymost setup, but i have no idea what it does.

That seems to be a menu bug, but there is a workaround. Go back to display options and change filter mode from classic to filtered. Now you can go back into polymost settings and you can turn palette emulation off. Then you can go back out and put filter back to classic, but palette emulation will stay off.

[Micky C]

Gambini, on 24 March 2018 - 03:06 PM, said:

Not sure what you mean, I only added the ExtClut thing.

BTW the palette emulation thing is locked on polymost setup, but i have no idea what it does.

ExtClut extends the palette options, but keeps the base palette the same.


Palette emulation attempts to make the colours in polymost closer to classic, by generating a new, individual texture for each shade variation of an art tile, and using that instead of simply making it darker by adding blackness, as has been done traditionally. Of course, polymost still adds blackness for visibility in the distance, so everything has to be very finely balanced for it to look close to classic. Although, by the sounds of things they're going to implement something like polymer's artmapping shader, which accounts for both shade and visibility in a classic-style through direct use of the lookup tables, potentially with some interpolation.

[Gambini]

Quote

That seems to be a menu bug, but there is a workaround. Go back to display options and change filter mode from classic to filtered. Now you can go back into polymost settings and you can turn palette emulation off. Then you can go back out and put filter back to classic, but palette emulation will stay off.

That seems to do the trick. And also proved that only the r_usetileshades 2 is the command I need.

However, It is still a problem. If I had to release the mod today players would have to deal with that workaround, which is something nobody would bother to.

What is palette emulation BTW? Is there a way to disable it through the console?

[Danukem]

Micky C, on 24 March 2018 - 04:41 PM, said:

Palette emulation attempts to make the colours in polymost closer to classic, by generating a new, individual texture for each shade variation of an art tile

That sounds like it would use a ton of resources in a project that adds thousands of new art tiles, such as AMT TC and lots of others.

[Gambini]

Micky C, on 24 March 2018 - 04:41 PM, said:

Palette emulation attempts to make the colours in polymost closer to classic, by generating a new, individual texture for each shade variation of an art tile, and using that instead of simply making it darker by adding blackness, as has been done traditionally. Of course, polymost still adds blackness for visibility in the distance, so everything has to be very finely balanced for it to look close to classic. Although, by the sounds of things they're going to implement something like polymer's artmapping shader, which accounts for both shade and visibility in a classic-style through direct use of the lookup tables, potentially with some interpolation.

That is what r_usetileshades do. TerminX implemented it kindof at my request in 2013 after DNF 2013 was released. Is it the same thing but with a fancy name?

There were two modes for it, and at the time i was inclined to use r_usetileshades 2 because it had a more accurate look to what i was needing. I think it would be good to have the two options, or at least a way to force the one I am using.

[Gambini]

Trooper Dan, on 24 March 2018 - 04:46 PM, said:

That sounds like it would use a ton of resources in a project that adds thousands of new art tiles, such as AMT TC and lots of others.

I have been using it since it exists and never had performance issues, even when i always keep an eye on the fps counter. 8bit tiles are usually 128x128, with all 24 shade tables for each, it´s still as big as a single material of 627x627, much smaller than most hrp textures for example.

[Micky C]

Gambini, on 24 March 2018 - 04:49 PM, said:

That is what r_usetileshades do. TerminX implemented it kindof at my request in 2013 after DNF 2013 was released. Is it the same thing but with a fancy name?

I'm pretty sure that's what it is. They needed a fairly simple non-technical yet descriptive name for the wider gaming community. I wouldn't be surprised if it went through some iteration since 2013, as the original implementation was quite crude.

Trooper Dan, on 24 March 2018 - 04:46 PM, said:

That sounds like it would use a ton of resources in a project that adds thousands of new art tiles, such as AMT TC and lots of others.

I assume it'd do some kind of check and only apply the process to a subset of the textures, i.e the ones actually being used. I recall TX saying that it'd have similar performance to something like the HRP.

I haven't noticed any unusually poor performance in the AMC TC in polymost, although I use classic 99% of the time, which doesn't use the emulation.

[Danukem]

Micky C, on 24 March 2018 - 05:05 PM, said:

I assume it'd do some kind of check and only apply the process to a subset of the textures, i.e the ones actually being used. I recall TX saying that it'd have similar performance to something like the HRP.

I haven't noticed any unusually poor performance in the AMC TC in polymost, although I use classic 99% of the time, which doesn't use the emulation.

I'll just have to keep an eye on performance when that setting is used, since in my current project I'm using all the sebabdukeboss20 characters, often with most of the different characters in a map at the same time, and they comprise thousands of tiles at about 64x128 pixels per frame. I have noticed some hitches lately.

[Hendricks266]

Palette Emulation being in the menu at all is a concession to the performance cost it had. It being locked reflects situations in which the performance concerns are solved. "On" is the correct setting. When this becomes all situations, the menu option will go away and it will again only be a cvar.

It would be a shame if a project so centered in history would say "I don't care" about actually looking accurate to the history it is imagining. I promise it won't be hard to fix your maps. Scripting is the answer here. Hopefully someone can spare the time to help. For example, a script that can apply shading modifiers to a selected group of sectors.

shade.m32:

gamevar i 0 0
gamevar j 0 0

defstate shadedown
  // handle RAlt selections
  for i selsectors
  {
    sub sector[i].floorshade 1
    sub sector[i].ceilingshade 1
    for j spritesofsector i
    {
      sub sprite[j].shade 1
    }
    for j wallsofsector i
    {
      sub wall[j].shade 1
    }
  }

  // handle RShift selections
  for j selsprites
  {
    sub sprite[j].shade 1
  }
  for j selwalls
  {
    sub wall[j].shade 1
  }
ends

console:

include shade

(select things)

do state shadedown

Repeat.

[Gambini]

The problem is the balance between shading and visibility is a math that requires an adjustment per case. You know shading affects visibility and vice-versa so finding an equation which restores the looks of distant bright constructions and at the same time dark closer ones is probably something only the engine knows.

I will be insolent and ask: What is the problem of allowing users access those commands? Come to think of it: nobody will fuck up with them, it´s improbable and your action would save us hours of work, which would be fair to spare, since we always been on the rules when building this. Polymost has been on development for 14 years, claiming we should not have relied on an unfinished renderer is not a valid point.

[Danukem]

Fox, on 24 March 2018 - 10:56 AM, said:

I recommend a custom shade table with 48 shades to get a result similar to 0.65.

Sent you a PM asking for help on this, and yes as we said DNF 2013 uses the same base palette. Your expertise would be much appreciated.

A scripting solution could be made to work, but I'm pretty sure it will take trial and error, using different scripts on different groups of sectors and still fine tuning the result in many cases...it will probably take quite a few hours to get it perfect on all the maps, which are quite large and complex.

[Fox]

Gambini, on 24 March 2018 - 07:08 PM, said:

The problem is the balance between shading and visibility is a math that requires an adjustment per case. You know shading affects visibility and vice-versa so finding an equation which restores the looks of distant bright constructions and at the same time dark closer ones is probably something only the engine knows.

I will be insolent and ask: What is the problem of allowing users access those commands? Come to think of it: nobody will fuck up with them, it´s improbable and your action would save us hours of work, which would be fair to spare, since we always been on the rules when building this. Polymost has been on development for 14 years, claiming we should not have relied on an unfinished renderer is not a valid point.

"Palette Emulation" is r_usetileshades. The option is acting weird because of WIP code of the shader.

The console commands were never intended to serve as tools for modders, but an interface for the user. Meaning that console commands may be changed, removed, etc with no concern for backwards compatibility.

Polymost was in development for a long time, but it was still not working as intended. The purpose has always been to look like classic. It would be equivalent of using a poorly adjusted computer.


Anyway, here is a solution. Add this to the defs:

globalflags 1
shadefactor 47

Then adjust the visibility in USER.CON to your liking:

define DEFAULTVISIBILITY        512

[Danukem]

Fox, on 25 March 2018 - 01:21 AM, said:

Then adjust the visibility in USER.CON to your liking:

define DEFAULTVISIBILITY        512

Here's the thing I don't get, though. Even if the def commands plus changing DEFAULTVISIBILITY gets the correct result in game, how will that help in mapster? Mapster doesn't use settings in USER.CON

The mapper needs to see what the levels will look like in-game while mapping.

[Gambini]

Hello.

I haven't been following new features progress closely but i'm tempted to ask, because I know these have been subject of discussion in the past times, so they may be already available:

Are model skyboxes featured already? If so, what i have to do to get one of myself working?

Exists a way to use fog without changing the sector´s palette?

When will palette emulation apply on models and voxels?

Thanks for the response.

@Hendrics266: The sound problem I reported is fixed. If you are interested on reading what was it: it seems that (at least on my end) If sound SFX volume goes below 53% it wont work at all, and will abruptly begin to work when turned up to the next notch.

[Fox]

Gambini, on 30 March 2018 - 07:31 PM, said:

Exists a way to use fog without changing the sector´s palette?

Yes, it's a structure called "fogpal".