Minor Feature request - subdivisions for quads (and atlasing)

[hippocoder]

Hiya,

Feature 1
As a minor feature request I think it would be pretty neat if you could specify at runtime if some sprites or tilemaps should be subdivided a little for the purposes of better vertex lighting as opposed to switching to per pixel lighting (since per pixel adds up fast with lots of lights and transparency). It would probably allow for some neat deformations in the shader as well for those wanting to do that.

Just a thought - I know we spoke about it before but I felt it might be one of those little features unavailable to Unity 2D users and enhance the value this end. It would need to be set at runtime on things though to target different platform quality I guess.

If not considered, it won't change anything, just means my game won't look quite as nice - as I said purely a minor aesthetic improvement

Feature 2
Another nice thing you could add would be the inclusion of generating another heightmap atlas, which unity would convert to a normal map, which matches the existing atlas. This would add rim lighting to sprites as you can do a classic photoshop emboss from within 2D Toolkit, or bevel on the heightmap from out to in, in a variety of styles. For the most part it would give excellent depth or rim lighting without any work on the user's part if tweakable. The only reason this feature is a request is for the higher-end systems such as desktop, and the fact it might be bloody tricky matching the atlas order, not to mention workflows. So that's a nice-to-have feature that could set it apart from Unity's 2D system as well, and again just switchable at runtime.

So the console/desktop could have rim lighting (with a basic clever tweakable heightmap generated from some tweakable parameters - say this colour+fudge should have more depth on the heightmap and that colour shouldn't - you could do this with a lookup ramp supplied for the purposes of making a decision what pixels need to be higher or lower) - or just a variety of classic embosses with sliders. You would not want to add pixels to anything, merely modify them for the heightmap which unity would convert to normal.

Again, both features aren't essential but merely icing.

[unikronsoftware]

Hiya,

Feature 1
As a minor feature request I think it would be pretty neat if you could specify at runtime if some sprites or tilemaps should be subdivided a little for the purposes of better vertex lighting as opposed to switching to per pixel lighting (since per pixel adds up fast with lots of lights and transparency). It would probably allow for some neat deformations in the shader as well for those wanting to do that.

Just a thought - I know we spoke about it before but I felt it might be one of those little features unavailable to Unity 2D users and enhance the value this end. It would need to be set at runtime on things though to target different platform quality I guess.

If not considered, it won't change anything, just means my game won't look quite as nice - as I said purely a minor aesthetic improvement

I've avoided dynamic tesselation for a few different reasons. Most of the time when increasing tesselation you'll likely need to adjust partition sizes as well, and rebuild the meshes. Updating large meshes in Unity is terribly inefficent from c# I dont think this can be implemented in such a way as to not be incredibily limiting / constrainted. Fine as a special case optimization obviously, but not generic.

If you want to hack this in this CAN be done in a fairly elegant manner (as far as hacks go).

Feature 2
Another nice thing you could add would be the inclusion of generating another heightmap atlas, which unity would convert to a normal map, which matches the existing atlas. This would add rim lighting to sprites as you can do a classic photoshop emboss from within 2D Toolkit, or bevel on the heightmap from out to in, in a variety of styles. For the most part it would give excellent depth or rim lighting without any work on the user's part if tweakable. The only reason this feature is a request is for the higher-end systems such as desktop, and the fact it might be bloody tricky matching the atlas order, not to mention workflows. So that's a nice-to-have feature that could set it apart from Unity's 2D system as well, and again just switchable at runtime.

So the console/desktop could have rim lighting (with a basic clever tweakable heightmap generated from some tweakable parameters - say this colour+fudge should have more depth on the heightmap and that colour shouldn't - you could do this with a lookup ramp supplied for the purposes of making a decision what pixels need to be higher or lower) - or just a variety of classic embosses with sliders. You would not want to add pixels to anything, merely modify them for the heightmap which unity would convert to normal.

Again, both features aren't essential but merely icing.

Synced atlas generation will very likely be a tk2d 2.5 feature. I've updated the trello to reflect this. Converting heightmaps to normals would have to be done prior to atlasing - its the derived normals that need to be atlased, otherwise the normal map filter will detect gradients incorrectly across seams. I'm planning on implementing this as a generic system so you'll be able to generate multiple atlases in sync.

[hippocoder]

If I understood this right, it would mean we would only need to make 1 heightmap sprite and 1 colour sprite, right - and you perform sorcery and it just works?

[unikronsoftware]

Just so I understand correctly, you're talking about creating a pair of sprites (normal & height) and tk2d generates to atlases with exactly the same layout so the same UVs can be used to sample from both, right?

[hippocoder]

Yes - I'd think it a lot more useful than that nonsense people are doing at the moment where they supply 4-8 images per frame and mix.

But Being able to supply pairs at the collection level may well enable easy and manageable normal maps. I guess after the atlas stage the user would need to go through unity's normal map feature and tweak it (unless you wrap this). Mostly the problem is just making sure that the atlases are the same. Most of the time they are.

An alternative would be that you attempt a little pixel magic to generate an automatic height/normal map for an atlas with some sliders, but I don't think it's needed at all. What are other people using normal maps saying?