Duke4.net Forums: Textures with glow maps...a bug? - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

Textures with glow maps...a bug?

User is online   Danukem 

  • Duke Plus Developer

#1

I am using some custom textures with glow maps. Sometimes they work fine, and sometimes it's like they get corrupted in-game and display with the entire texture glowing and frakked up.

Here's an example:

Posted Image

Once this starts happening, then the texture will be corrupted like that for the duration of the game. It doesn't matter whether I am in Polymer or Polymost, or whether I restart EDuke32 and load the saved game. All appearances of the texture will be messed up. Interestingly, it never happens in Mapster.

I have only see this happen on textures that have glow maps. Any ideas on what is causing this or how to avoid it?

EDIT: Turning glow textures off in the video menu fixes it (at the expense of not having a glow texture, of course), so this confirms it is a problem with displaying the glow map.
EDIT2: I restarted the game and then turned glow textures back on and...this time it displayed correctly. So at least I have a workaround for players who encounter the problem.

This post has been edited by Trooper Dan: 25 April 2016 - 09:45 PM

0

User is online   Danukem 

  • Duke Plus Developer

#2

Here's a more detailed demonstration of the rendering issue. Again, this happens with both Polymer and Polymost. I updated my graphics driver and it still happens.

Posted Image

Uh oh! This texture with a glow map has started glitching. It will keep doing this on every surface with that picnum for the duration of the game, even if I restart EDuke32.

Posted Image

Turning off glow textures in the EDuke32 menu will stop the glitching. But I lose the glow.

Posted Image

If I turn glow textures back on, it will glitch again, unless I quit EDuke32 and load the saved game before turning them back on.
0

User is offline   Tea Monster 

  • Polymancer

#3

There is a bug with custom textures and glow/spec/normal maps. On our stuff they don't show up at all.

I've reported it to Plagman and am awaiting news.

If you want to contact him and provide him with a use case or test file, that would probably help.
0

User is online   Danukem 

  • Duke Plus Developer

#4

View PostTea Monster, on 26 April 2016 - 03:53 AM, said:

There is a bug with custom textures and glow/spec/normal maps. On our stuff they don't show up at all.

I've reported it to Plagman and am awaiting news.

If you want to contact him and provide him with a use case or test file, that would probably help.


I'll wait around and see what happens with PolymerNG. icecoldduke's renderer will have a whole different set of bugs and then this particular one won't be an issue :angry:
0

User is offline   Hendricks266 

  • Weaponized Autism

  #5

Does whether or not you have the texcache enabled affect this bug?
0

User is offline   Tea Monster 

  • Polymancer

#6

Not tried that. It was introduced in build 5400. Interestingly, it was introduced in October of last year, and nobody has seemed to have noticed it since then.

More detailed report here: https://forums.duke4...nt-and-polymer/
0

User is online   Danukem 

  • Duke Plus Developer

#7

View PostHendricks266, on 26 April 2016 - 12:44 PM, said:

Does whether or not you have the texcache enabled affect this bug?


I do not know whether the glitched glowmaps can start to appear if texcache is disabled. I do know this: once they start appearing, deleting the texture cache is not sufficient to make them go away. I have to actually disable glow maps and then restart the game before turning them on again (this doesn't always do the trick, either). The glitched texture will even appear as such in the preview image of the saved game.

By the way, I am not assuming that this is the same issue that Tea Monster is reporting. One involves glow and other maps not showing up on models, my issue involves glow maps glitching and taking over textures.
0

User is offline   Mark 

#8

are your glowmap textures PNG with transparent backround?
0

User is online   Danukem 

  • Duke Plus Developer

#9

View PostMark., on 26 April 2016 - 02:55 PM, said:

are your glowmap textures PNG with transparent backround?


Yes, that's exactly how I do it. Is there a better alternative?
0

User is offline   Hank 

#10

View PostTrooper Dan, on 26 April 2016 - 06:57 PM, said:

Yes, that's exactly how I do it. Is there a better alternative?

Technically, and I am too lacy to test this, a simple black (not blank) and white image will do.


Is there a wiki that explains all map types (for textures) that are supported by EDuke32 and what to look out for when making them?

This post has been edited by Hank: 26 April 2016 - 08:12 PM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #11

View PostHank, on 26 April 2016 - 08:10 PM, said:

Technically, and I am too lacy to test this, a simple black (not blank) and white image will do.

Glow maps are simply overlaid on top of the base texture.

While your idea of a glow mask is very interesting as a performance-saving measure, it wouldn't work for ye old Polymost. :angry:
0

User is online   Danukem 

  • Duke Plus Developer

#12

I have other players reporting this bug now, too. What a shame. I'll have to tell them to turn off glow maps, I guess. I did notice that there were some changes involving texture caching in the latest build, so I hope that helps (can't confirm yet).
0

User is online   Danukem 

  • Duke Plus Developer

#13

When I changed over to the latest snapshot, FIRSTGUNSPRITE (tile 21) was replaced with a random part of a texture having the dimensions of the pistol. The actor functioned normally but it appared as a different tile number. I deleted the texture cache files and the problem went away...for now. Since we can assume that most players will not be deleting their texture cache when they switch to a new snapshot, this is a problem.
0

User is offline   Spiker 

#14

Add "purge texture cache" button in the starting window Posted Image
0

#15

View PostTrooper Dan, on 05 May 2016 - 11:25 AM, said:

When I changed over to the latest snapshot, FIRSTGUNSPRITE (tile 21) was replaced with a random part of a texture having the dimensions of the pistol. The actor functioned normally but it appared as a different tile number. I deleted the texture cache files and the problem went away...for now. Since we can assume that most players will not be deleting their texture cache when they switch to a new snapshot, this is a problem.

This is one reason why shipping with precompiled assets is a good thing :angry:.
-1

User is offline   Hendricks266 

  • Weaponized Autism

  #16

I'm sorry I don't have time to look at this right now. Is every glowmap you define affected by the original issue, or just certain ones? If the latter, is it deterministic or random?

EDIT: If the latest snapshot broke something in texcache, then I do need to look this at right now for HTTKC. I'm glad I pushed the change so it could get tested. For now, roll back.

View Posticecoldduke, on 05 May 2016 - 11:51 AM, said:

This is one reason why shipping with precompiled assets is a good thing :angry:.

Nice shitpost. My texcache improvements having a bug is not a point in favor of something that doesn't use a texcache.

This post has been edited by Hendricks266: 05 May 2016 - 12:12 PM

0

#17

View PostHendricks266, on 05 May 2016 - 12:07 PM, said:

Nice shitpost. My texcache improvements having a bug is not a point in favor of something that doesn't use a texcache.

I actually wasn't even talking about the Eduke32 texcache in particular. I have worked on many projects that have had mega files for various reasons, and no matter how much engineering goes into making sure these mega files don't get fucked up...they always end up getting fucked up. Which is why mega files are great when you build them from scratch and send them out in a build. They aren't so great when users have to keep updating them, cause eventually they have to get deleted and rebuilt. This is ok for developers, no so much for end users.

My comment wasn't directed at you or even EDuke32, it was directed at Trooper Dan cause of our back and forth in the other topic :angry:.

This post has been edited by icecoldduke: 05 May 2016 - 12:27 PM

0

User is offline   Hendricks266 

  • Weaponized Autism

  #18

View Posticecoldduke, on 05 May 2016 - 12:22 PM, said:

I actually wasn't even talking about the Eduke32 texcache in particular.

My comment wasn't directed at you or even EDuke32, it was directed at Trooper Dan cause of our back and forth in the other topic :angry:.

I don't see how that can be true. It's the exact same subject.

You quoted Dan's post about the texcache and made that quip... and it's not about the texcache? Really?

I'm not upset (since it clearly wasn't personal), but discussion about PolymerNG development continually reminds me of a situation I lived through for a substantial portion of my life, where the cool kids and their cronies would make fun of me for caring about things that didn't matter to them.



me: "It's not a point in the school's favor to claim we prepare students for the SAT by teaching to the test."

them: "No one cares." <snicker>



me: "X is wrong with PolymerNG."

them: "PolymerNG is shiny, and I've waited for so long! No one cares." [sends emails to icecoldduke]

This post has been edited by Hendricks266: 05 May 2016 - 12:42 PM

2

User is online   Danukem 

  • Duke Plus Developer

#19

When I have more information, I'll provide it. Since I have already deleted the texcache, I'll have to wait and see if problems occur again. In the mean time, could new snapshots which modify texture caching set a flag that forces the texture cache to rebuild?
0

User is offline   Hendricks266 

  • Weaponized Autism

  #20

There was not supposed to be any functional change in those commits, but otherwise we would bump the texcache version number (and we have before). I need to extend its functionality for HTTKC anyway, and a version bump will be part of it.
0

#21

View PostHendricks266, on 05 May 2016 - 12:32 PM, said:

I don't see how that can be true. It's the exact same subject.

You quoted Dan's post about the texcache and made that quip... and it's not about the texcache? Really?

I'm not upset (since it clearly wasn't personal), but discussion about PolymerNG development continually reminds me of a situation I lived through for a substantial portion of my life, where the cool kids and their cronies would make fun of me for caring about things that didn't matter to them.



me: "It's not a point in the school's favor to claim we prepare students for the SAT by teaching to the test."

them: "No one cares." <snicker>



me: "X is wrong with PolymerNG."

them: "PolymerNG is shiny, and I've waited for so long! No one cares." [sends emails to icecoldduke]

The intent of what I posted was strictly to attack a point Trooper Dan was making in the PolymerNG topic. I basically wanted to reenforce my belief that shipping with prebuilt data is the way to go for new mods. Its enevitable that end user will have to delete and rebuild mega files and time goes on. It doesn't matter how much quality work you put in, eventually that file will have to get rebuilt.

To the big point of your reponse; If you believe, anyone on here has been disrespecting you more because of me, then this needs to be addressed here and now. It has never been my intention to indicidate any of the work you do here on EDuke32 is bad in any way. I need everyone on here to really internalize that last statement.

I want to build a awesome Next Generation renderer, that is fast and efficient. I hope you can see how my approach to problems thus far has lead to results; I point to current builds of PolymerNG, and how well it can run Clear the Coast(even better then regular Polymer). The intent isn't to make you look bad, the fact is you saved my ass more then once(just look at the sound code, remember I wanted to write new XAudio code :angry: ). I really want to work with you to make sure my efforts conform with the idea of the build engine. I want to be able to work with you on developing tech that goes into PolymerNG.

I'll talk about tech in the other topic, but I hope that you accept my sincere apology. I hope the rest of you really take to heart what I said. This is a team effort.

As a side note sorry to hi-jack the thread :lol:.
0

User is offline   Hendricks266 

  • Weaponized Autism

  #22

I'm also sorry for escalating drama where we don't need any.

View Posticecoldduke, on 05 May 2016 - 03:13 PM, said:

If you believe, anyone on here has been disrespecting you more because of me, then this needs to be addressed here and now.

You are not to blame for anyone else's disrespect. :angry:

View Posticecoldduke, on 05 May 2016 - 03:13 PM, said:

I basically wanted to reenforce my belief that shipping with prebuilt data is the way to go for new mods.

I'm convinced that loading prebuilt data is a good option, perhaps the best option for performance. I'm not convinced it should be the only option.
3

User is offline   Jblade 

#23

Quote

I basically wanted to reenforce my belief that shipping with prebuilt data is the way to go for new mods. Its enevitable that end user will have to delete and rebuild mega files and time goes on. It doesn't matter how much quality work you put in, eventually that file will have to get rebuilt.

This is silly and the whole point of working with old game mods is that you don't have to deal with this kind of bullshit. I still have no idea why you're intent on trying to force this level of professionalism on modding a 20 year old game than some of us just do in the evening to wind down after work.

I respect the work you're doing but you have to understand a lot of us modders have no actual interest in the games industry or trying to adopt its practices of 'shipping' or whatever.
3

User is offline   Hendricks266 

  • Weaponized Autism

  #24

View PostTrooper Dan, on 05 May 2016 - 11:25 AM, said:

When I changed over to the latest snapshot, FIRSTGUNSPRITE (tile 21) was replaced with a random part of a texture having the dimensions of the pistol. The actor functioned normally but it appared as a different tile number. I deleted the texture cache files and the problem went away...for now. Since we can assume that most players will not be deleting their texture cache when they switch to a new snapshot, this is a problem.

Have you seen this problem since then, either in an ART tile or in a hightile?
0

User is online   Danukem 

  • Duke Plus Developer

#25

View PostHendricks266, on 04 June 2016 - 03:06 PM, said:

Have you seen this problem since then, either in an ART tile or in a hightile?


The bug with the random tile replacement? No, I have not.
0

Share this topic:


Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options