[Steveeeie]

Would love to also see a model viewer and material editor so that content creators can quickly adjust their models without having to reboot the game when tweaking, would also be useful if it exported the con code too.

[icecoldduke]

Steveeeie, on 25 June 2016 - 02:58 PM, said:

This is really starting to looks sweeeeeeeeeeeeeeeeeeeet.

When we going to see more from the 3d sprites and when will we start to see materials?

If you still plan to do PBR can we go with the metalness workflow as opposed to the specular workflow?

So the next goal I have is to get the performance under control, and clear up the bugs we talked about a few posts up. I want to get this part working 100% then I can move on to materials. Once materials attributes working I can move on to PBR. I want to get each milestone as bug free as possible before moving on, so PBR is still in the pipe, don't worry I'm just working up to it. The reason why I got mapster working at this stage was to help me with bug fixes and performance fixes.

[Micky C]

Steveeeie, on 25 June 2016 - 03:02 PM, said:

Would love to also see a model viewer and material editor so that content creators can quickly adjust their models without having to reboot the game when tweaking, would also be useful if it exported the con code too.

You mean def code?

MusicallyInspired, on 25 June 2016 - 01:55 PM, said:

No, I don't. I'm talking about a realtime instant toggle between editor and game modes. If I launch the game I can't press CTRL+P and enter editor mode.

There is a test option in mapster which instantly boots the map into the game with the starting your position at the current position which is pretty useful. You can test stuff out, then simply close eduke and continue working in the editor. Still, there's a tiny amount of time between switching which starts to add up if you do it frequently (and is probably a lot longer when using high res assets and models). Plus it might be nice to get a point in the map, and want to go straight to that point in the editor when you close, so I can see the advantages.

[Steveeeie]

Micky C, on 25 June 2016 - 05:43 PM, said:

You mean def code?

Yep, sorry

[Plagman]

Hey, all the material properties are editable from in-game through the override CVARs. If you're restarting the game to tweak specular or parallax material properties you're doing it wrong. I think someone made an m32script where you could just tweak them with hotkeys too

[Kyanos]

Quote

r_pr_overridespecular overrides specular material power and factor values with values from the pr_specularpower and pr_specularfactor cvars; use it to fine-tune DEF tokens 0 1 0

from the wiki

so how do it work

like this? r_pr_overridespecular <TILENUM> <VALUE> ??

[icecoldduke]

Plagman, on 26 June 2016 - 10:11 AM, said:

Hey, all the material properties are editable from in-game through the override CVARs. If you're restarting the game to tweak specular or parallax material properties you're doing it wrong. I think someone made an m32script where you could just tweak them with hotkeys too

Drek, on 26 June 2016 - 10:19 AM, said:

from the wiki

so how do it work

like this? r_pr_overridespecular <TILENUM> <VALUE> ??

I agree if your having to restart the game to edit materials then that is a awful workflow, but I don't think the cvar approach is great either(since it doesn't directly save to the material), is there currently a reloaddefs/reloadmaterials command in the console?

[Kyanos]

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

I agree if your having to restart the game to edit materials then that is a awful workflow, but I don't think the cvar approach is great either(since it doesn't directly save to the material), is there currently a reloaddefs/reloadmaterials command in the console?

Not documented on the wiki, so probably no.

Reloading defs ingame would be a huge time saver.

[Plagman]

Drek, on 26 June 2016 - 10:19 AM, said:

from the wiki

so how do it work

like this? r_pr_overridespecular <TILENUM> <VALUE> ??

You just set the first cvar to 1 to enable override mode, then you fine-tune power and factor through the other two cvars it says to use. You do have to alt-tab and write it out to the DEF file when you find the good values, but at least you're not rerunning the game just to test a different value.

[icecoldduke]

So I lied I've been working on normal mapping, and I have a question, is there anything special with some of the normal maps? If you look at the doors in this screenshot, I had to re-export the normal map with the NVIDIA normal map plugin, before that the lighting on this door looked awful. I'm talking about tile 821. I looked at the normal map in photoshop and nothing seemed too off about it. I'd like to get a second pair of eyes. Here is a screenshot of the door actually working. I'm having a similar issue with tile 757, and 1204.

[TerminX]

You should fix the high res texture scaling first, don't you think? It has been wrong for as long as you've had high res textures implemented and I've been waiting for you to notice it.

[Tea Monster]

You'd need to check with the pack maintainers, but from what I heard, they used PNG out to crunch down the maps. It could be that if you are putting further compression onto already compressed maps, that it could be causing some of the issues. The other thing is that some of the maps are actually parallax maps, with a height map in the alpha channel. Don't know if that could be causing issues.

[icecoldduke]

TerminX, on 26 June 2016 - 12:43 PM, said:

You should fix the high res texture scaling first, don't you think? It has been wrong for as long as you've had high res textures implemented and I've been waiting for you to notice it.

That's on my todo list . I'm just avoiding the def file code, huge mega functions = awful. I'll get that fixed don't worry.

Tea Monster, on 26 June 2016 - 12:48 PM, said:

The other thing is that some of the maps are actually parallax maps, with a height map in the alpha channe

That's possible, I can confirm I re-exported the above normal maps and everything looks fine now.

[Mark]

A couple of years ago I made a list of the "one-sided" HRP textures under Polymer. As in they illuminate with a light from the left but not from the right ( or vice-versa ). And a light from straight on filled only part of the surface. If I can find that list again I will post it here.

[Plagman]

You haven't shown the broken example so it's hard to theorize what was wrong. Also, what do you mean re-exported? You loaded the normal map in the tool and saved it? Are you using the magnitude of the normal vectors from the map or just the direction? The tool could have just normalized the vectors, which would have made a difference if you're accidentally using the magnitude to scale the lighting contribution.

[Steveeeie]

icecoldduke, on 26 June 2016 - 12:51 PM, said:

That's possible, I can confirm I re-exported the above normal maps and everything looks fine now.

The NVIDIA normal map plugin will have removed the alpha channel as normal maps should have no transparency.

Like others have said as the alpha channel is not needed by the normal map, content creators are utilising the spare channel to store the displacement / parallax maps so it doesn't have to require its own file and saves some space.

[icecoldduke]

Plagman, on 26 June 2016 - 01:34 PM, said:

You haven't shown the broken example so it's hard to theorize what was wrong. Also, what do you mean re-exported? You loaded the normal map in the tool and saved it? Are you using the magnitude of the normal vectors from the map or just the direction? The tool could have just normalized the vectors, which would have made a difference if you're accidentally using the magnitude to scale the lighting contribution.

You are correct I should have screen grabbed the fail case, in order for that to happen I have re-run the texture payload tool with the fail case in the data and I'm not able to do that right now. All I did was generate a normal map with the NVIDIA Photoshop normal map plugin and exported it out. I am not accidentally scaling the light contribution by anything, but that was a good idea. This is definitely a data issue, I'm just not sure if its because I'm handling something improperly, or because bad data slipped through.

It's possible the alpha channel has something to do with it(might be an error in the texture payload generation tool), I'll double check if any of the other normal maps that work have a alpha channel.

[Steveeeie]

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

You are correct I should have screen grabbed the fail case, in order for that to happen I have re-run the texture payload tool with the fail case in the data and I'm not able to do that right now. All I did was generate a normal map with the NVIDIA Photoshop normal map plugin and exported it out. I am not accidentally scaling the light contribution by anything, but that was a good idea. This is definitely a data issue, I'm just not sure if its because I'm handling something improperly, or because bad data slipped through.

It's possible the alpha channel has something to do with it(might be an error in the texture payload generation tool), I'll double check if any of the other textures that work have a alpha channel.

You should only be taking RGB channels into consideration for normal maps, other engines will usually strip the alpha channel out themselves on compile.

Related Note: If you are looking to reduce file size by compiling the textures, a lot of other engines will strip out the blue channel from normal maps on compile. This is because the blue channel is always an even spread of 100% grey, you could fake this channel being there through code which other engines do.

[icecoldduke]

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

You should only be taking RGB channels into consideration for normal maps, other engines will usually strip the alpha channel out themselves on compile.

Related Note: If you are looking to reduce file size by compiling the textures, a lot of other engines will strip out the blue channel from normal maps on compile. This is because the blue channel is always an even spread of 100% grey, you could fake this channel being there through code which other engines do.

When sampling from the normal map I only use the RGB channels, but when the data gets saved out to the payloads it does get DXT5 compressed(which isn't ideal for normal maps), its possible thats fucking it up.. It's a stretch but its something I can't rule out without testing.

[Plagman]

Naive DXT compression on normal maps is bad news, you'll definitely want to avoid that.

[Mark]

Steevie said: "... normal maps should have no transparency."

Some of the best performing HRP tiles have normal map textures with partial transparency.

[Steveeeie]

Mark., on 26 June 2016 - 02:56 PM, said:

Steevie said: "... normal maps should have no transparency."

Some of the best performing HRP tiles have normal map textures with partial transparency.

You are failing to see how they work.

Normal maps should never be transparent, its just not how they work. The only channels that really matter are the red and green channels.

The HRP normals only appear to be transparent if viewed in photoshop or explorer because content creators are storing parallax maps in the alpha slot.

[icecoldduke]

Plagman, on 26 June 2016 - 02:36 PM, said:

Naive DXT compression on normal maps is bad news, you'll definitely want to avoid that.

Oh I know I just haven't added multi compression type support to the payload format yet. I guess now is the best time to do that .

[Kyanos]

removed-wrong thread

[LeoD]

Tea Monster, on 26 June 2016 - 12:48 PM, said:

You'd need to check with the pack maintainers, but from what I heard, they used PNG out to crunch down the maps. It could be that if you are putting further compression onto already compressed maps, that it could be causing some of the issues.

As long as number of channels and colour depth are untouched : No. (At least no entries/changes since 2012 are affected.)

Mark., on 26 June 2016 - 01:34 PM, said:

A couple of years ago I made a list of the "one-sided" HRP textures under Polymer. As in they illuminate with a light from the left but not from the right ( or vice-versa ). And a light from straight on filled only part of the surface. If I can find that list again I will post it here.

I saved a bookmark.

[icecoldduke]

When it comes time to release the single level demo, does anyone object to me including the texture payloads file that contains the HRP textures? Right now its 298mb, but that size should drop some when I add support for other DXT compression methods. The alternative is you guys have to generate the texture payloads file with the "virtualtexture" tool, and I think that would be silly for the test.

[HiPolyBash]

I wouldn't object to it being bundled.

[Tea Monster]

No problem.

[Kyanos]

Both?

[HiPolyBash]

Drek, on 28 June 2016 - 05:07 AM, said:

Both?

You are an incredibly innovative thinker and a man that possesses wonderful intellectual ability.