[Bugs] Moth Lamp

[debugman18]

Sure, but I needed a concrete example to work on.

The game just blows minor artifacts way out of proportion. This is the actual mipmap chain of the crystal axe, with a black background:

You can certainly see the artefacts in the same position the appear in-game, but they're much, much smaller.

EDIT: Actually, they are in the source image (as can be seen by the primary mipmap having them). This is the png of the crystal axe on a black background:

If you can give me another example, where the source image itself is not compromised, I'd appreciate it.

 

The vines are doing it again, as well. I'm pretty sure that there's no stray alpha in it's atlas.

 

As well as skyflowers and the worldgen screen.

 

[simplex]

The vines are doing it again, as well. I'm pretty sure that there's no stray alpha in it's atlas.

 

As well as skyflowers and the worldgen screen.

I noticed it in the vines as well, but not on skyflowers. There a bit on top of tea bushes when I zoom out as well. I'm not seeing it everywhere, as you put it, but it's definitely common.

I'm trying another filter. Don't change the assets, or we'll have a horrible merge .

[debugman18]

I noticed it in the vines as well, but not on skyflowers. There a bit on top of tea bushes when I zoom out as well. I'm not seeing it everywhere, as you put it, but it's definitely common.

I'm trying another filter. Don't change the assets, or we'll have a horrible merge .

 

I've got a whirlwind atlas, but I'll put it aside for now.

 

And everywhere is an exaggeration, I guess.

 

[simplex]

I've got a whirlwind atlas, but I'll put it aside for now.

 

And everywhere is an exaggeration, I guess.

Don't worry, I'll fix it. Eventually .

There might be a hidden bug in ktech somewhere, we're getting too extreme results.

But I'm having trouble finding a proper example to use as a test base, since each one I check has the issue in the source image itself. For example, this is the vine atlas on a black background:

And this is the mipmap chain (this is using the Mitchell filter, but it only looks slightly better than bicubic in game):

As you can see, the real issue is in the primary mipmap (the original image). The stray pixels are actually being reduced on mipmap generation (I guess the cubic filter was simply so blurry that it was getting rid of them completely ).

And by the way, the default filter of Klei's TextureConverter is Lanczos.

[debugman18]

Don't worry, I'll fix it. Eventually .

There might be a hidden bug in ktech somewhere, we're getting too extreme results.

But I'm having trouble finding a proper example to use as a test base, since each one I check has the issue in the source image itself. For example, this is the vine atlas in a black background:

And this is the mipmap chain (this is using the Mitchell filter, but it only looks slightly better than bicubic in game):

As you can see, the real issue is in the primary mipmap (the original image). The stray pixels are actually being reduced on mipmap generation.

And by the way, the default filter of Klei's TextureConverter is Lanczos.

 

Try the worldgen animation. That image is perfect. It was last time I checked, anyway.

 

[simplex]

@debugman18

So... I did some things.

And in the above, both the vine and the wind axe atlas had their mipmaps generated with the Lanczos filter (which I made the default once again).

What changed is that now I'm premultiplying alpha per mipmap, instead of doing it for the primary mipmap and then generating the other mipmaps from the already premultiplied one. Additionally, I'm applying a median filter to the alpha channel to smooth out irregularities in it (prior to alpha premultiplication).

I'll push the recompiled assets and the revised ktech code shortly.

[debugman18]

@debugman18

So... I did some things.

And in the above, both the vine and the wind axe atlas had their mipmaps generated with the Lanczos filter (which I made the default once again).

What changed is that now I'm premultiplying alpha per mipmap, instead of doing it for the primary mipmap and then generating the other mipmaps from the already premultiplied one. Additionally, I'm applying a median filter to the alpha channel to smooth out irregularities in it (prior to alpha premultiplication).

I'll push the recompiled assets and the revised ktech code shortly.

 

 

That's awesome, I hope it wasn't too hard to sort out. So you killed two birds with one stone? Making the image quality better without the stray semi-transparent alpha?

[simplex]

 

That's awesome, I hope it wasn't too hard to sort out. So you killed two birds with one stone? Making the image quality better without the stray semi-transparent alpha?

Yep, two birds with one stone . I think the most significant change was premultiplying alpha after mipmap generation, but since I implemented both things at the same time I can't be sure.

I just pushed the recompiled assets. It seems all issues are gone, but let me know if you still spot some stray white pixels. The radius for averaging alpha values may need some tweaking.

I also pushed the revised ktech code, you'll need to recompile it. And I fixed a bug in it: the game's textures have premultiplied alpha, but I wasn't "demultiplying" (dividing?) it when converting from tex to png, which produced incorrect pngs from texes with transparency. Now this is done properly.

I recommend running "make -B" at least once, it's a beautiful thing . (but run "git reset --hard HEAD" afterwards, of course, and only do this if your working tree has no modifications, otherwise the git reset will discard them).

[debugman18]

Yep, two birds with one stone . I think the most significant change was premultiplying alpha after mipmap generation, but since I implemented both things at the same time I can't be sure.

I just pushed the recompiled assets. It seems all issues are gone, but let me know if you still spot some stray white pixels. The radius for averaging alpha values may need some tweaking.

I also pushed the revised ktech code, you'll need to recompile it. I also fixed a bug in it: the game's textures have premultiplied alpha, but I wasn't "demultiplying" (dividing?) it when converting from tex to png, which produced incorrect pngs from texes with transparency. Now this is done properly.

I recommend running "make -B" at least once, it's a beautiful thing . (but run "git reset --hard HEAD" afterwards, of course, and only do this if your working tree has no modifications, otherwise the git reset will discard them).

 

I know about git reset --hard. I use it like this sometimes git reset --hard 'HEAD^' to go back a commit, also..

 

Checked it out, I'm not seeing any issues.

[simplex]

Checked it out, I'm not seeing any issues.

Great! But do let me know if you spot any. The averaging radius for alpha certainly played a role, since the wind_axe inventory image only got really clean after I increased it. So it may need to be increased further still to fix other issues (though hopefully not by much, since then it might affect the borders of atlases with semitransparent images).

[debugman18]

The only troublesome bug that remains is the whirlwind saving bug. It's a guaranteed freeze if I force a save while a whirlwind is active.

[simplex]

The only troublesome bug that remains is the whirlwind saving bug. It's a guaranteed freeze if I force a save while a whirlwind is active.

Hopefully I'll have some time from all these C++ and Python issues to take care of the Lua ones .

[debugman18]

Hopefully I'll have some time from all these C++ and Python issues to take care of the Lua ones .

 

So I was wondering if you could tell me what the blue square represents on selected debug entities...

 

I've been trying to figure out how to make our custom animated objects clickable, and what I saw with those squares suggests that it represents the clickable area. It also has a MASK field in the physics debug strings, which is empty, while, for instance, the sanityrock's mask field is not.

[simplex]

So I was wondering if you could tell me what the blue square represents on selected debug entities...

Never seen them, so I can't help.

I've been trying to figure out how to make our custom animated objects clickable, and what I saw with those squares suggests that it represents the clickable area. It also has a MASK field in the physics debug strings, which is empty, while, for instance, the sanityrock's mask field is not.

That mask is the collision mask, not related. Not related to physics in general. It's the scml compiler that needs to be extended.

[debugman18]

Never seen them, so I can't help.

That mask is the collision mask, not related. Not related to physics in general. It's the scml compiler that needs to be extended.

 

If you do SetDebugEntity(TheInput:GetWorldEntityUnderMouse()) it brings up a debug overlay. I noticed that where the blue box overlaps the animation, it's clickable.

 

The one for the sanityrock, for instance, is much larger than the image itself, yet ours are almost always very small. Our dragonblood tree animations have the best clickable area out of all of the custom ones, and even theirs is off-center.

[simplex]

If you do SetDebugEntity(TheInput:GetWorldEntityUnderMouse()) it brings up a debug overlay. I noticed that where the blue box overlaps the animation, it's clickable.

I just tried it with a beefalo, and I got nothing. No overlay.

[debugman18]

I just tried it with a beefalo, and I got nothing. No overlay.

 

You may have to hit backspace.

 

 

[simplex]

You may have to hit backspace.

Mistery solved .

Wow, this debug entity HUD is so useful. Now I'm glad I made gimme() set the spawned entity as the debug entity (I did this just to have it accessible via c_sel()).

Yes, this appears to be the bounding box of the entity. If some Klei developer ever decides to drop by these lands and clarify how the bounding box is stored in the animation data, this should be quite handy for testing the scml compiler support.

[debugman18]

Mistery solved .

Wow, this debug entity HUD is so useful. Now I'm glad I made gimme() set the spawned entity as the debug entity (I did this just to have it accessible via c_sel()).

Yes, this appears to be the bounding box of the entity. If some Klei developer ever decides to drop by these lands and clarify how the bounding box is stored in the animation data, this should be quite handy for testing the scml compiler support.

 

I'd suggest summoning one of them, but that's not 100% reliable.

 

Isn't there a new mod subforum guy?

[simplex]

I'd suggest summoning one of them, but that's not 100% reliable.

 

Isn't there a new mod subforum guy?

That's what I did a few days ago.

Is there? I don't think so.

[debugman18]

That's what I did a few days ago.

Is there? I don't think so.

 

Well, http://forums.kleientertainment.com/user/275758-bizziboi/ and http://forums.kleientertainment.com/user/305402-sethr/ seem to be helpful, but they're not assigned to modders.

 

I miss Cheerio and Ipsquiggle. :/

 

 

[simplex]

Well, http://forums.kleientertainment.com/user/275758-bizziboi/ and http://forums.kleientertainment.com/user/305402-sethr/ seem to be helpful, but they're not assigned to modders.

Yes, they're helpful. But SethR has only interacted with modders a few times (understandable, considering RoG has essentially two programmers, him and Bryce) and biziboi... well, he's new, with just a couple posts (all but one among the recent posts on DLC support at worldgen ), so I don't know what he's about.

It was nice to have Cheerio and Ipsquiggle around. They could've given some notice about their leave instead of just disappearing...

[debugman18]

Yes, they're helpful. But SethR has only interacted with modders a few times (understandable, considering RoG has essentially two programmers, him and Bryce) and biziboi... well, he's new, with just a couple posts (all but one among the recent posts on DLC support at worldgen ), so I don't know what he's about.

It was nice to have Cheerio and Ipsquiggle around. They could've given some notice about their leave instead of just disappearing...

 

That makes me wonder what they're working on now.

 

Well, maybe JoeW could enlighten us about how to go about fixing the clickbox? Or point us in the right direction, or point a developer in our direction.

[simplex]

Well, maybe JoeW could enlighten us about how to go about fixing the clickbox? Or point us in the right direction, or point a developer in our direction.

I think JoeW takes care of just forumy, web programming/administration stuff. He could act as a middle man to ask a developer to drop by, but I'd feel a bit awkward asking him to summon someone here.

[debugman18]

I think JoeW takes care of just forumy, web programming/administration stuff. He could act as a middle man to ask a developer to drop by, but I'd feel a bit awkward asking him to summon someone here.

 

I don't see anything wrong with it, since Ipsquiggle and Cheerio seem to be absent (also, the mod tools never made it out of alpha?), and we don't know who to ask about it. Of course, we could always just kick stuff around until we figure it out.

 

Would making a component to attach an invisible vanilla asset to a given converted animation work? Doesn't the balloon hound's balloon's clickbox act as part of the hound's?