Pivot Point Rotation 2.0

[Majicpanda]

Is there no longer a custom pivot point available in 2.0? I'm not seeing it in the sprite collection editor (but not really what I want anyway)

What I have is a bunch of weapons where the handle is in the exact same point in the image for each, so I need to (preferably in code and not all 500+ sprites) rotate around a specific point in the image so the weapon does an attack type motion.

I thought there was a way to child the sprite to a GO and just rotate it that way but I'm not able to see the way to do it.

[unikronsoftware]

1. There is. You need to set anchor type to "Custom" and then you'll be able to change it.

2. You just create the sprite at runtime and then add a child gameobject - nothing should stop you from doing that. You should be able to rotate it whatever way you like in code.

[Majicpanda]

What would you suggest for a universal equip system for 2.0? Can you set the anchor in code? All my weapons will have the exact same X/Y pivot of 28/33 and I don't see any way to modify the anchor in code or do a batch import (that would be awesome to specify anchor at import time of 500 images).

To get around this I'm suggesting my artist create all weapons directly in the center of the 32x32 image with the weapon "grip point" the same so that I can make each race in our game have a child object for "Hand" and then just move the sprite Go to that location.  Does this sound logical?  It would also solve the rotation issue.

I feel I'm maybe not using the kit to its potential... untrimmed images is a complete waste of transparency space and I have to tell each atlas not to trim so that I can overlay images onto each other.  If my artist makes a character, pants, helmet, etc all in a 32x32 area then I just render different Z depth to "equip" them by laying every 32x32 image on top of each other.  Animations and everything else get completed messed up if you export trimmed images in photoshop, so is this normal to use full size images for pixel art like this?

[unikronsoftware]

There will be an attach point system in 2.1 which could work quite well for this. More details here:
https://trello.com/b/UfqlXqXy

2D Toolkit automatically trims your images for you, so you can actually just export untrimmed images from photoshop with a fixed anchor point. Should make things a LOT easier to deal with.

[Majicpanda]

That sounds like a really interesting feature and I'll definitely take a look once it's live.

I was having really weird issues on iOS with small texture "flashing" odd anomalies at times with trimming on so I disabled it.  All our art is 40x40 pixel area images imported into a tk2d sprite collection with ortho target 10 and target height 126.  Clamp, uncompressed point texture settings.  When we checked disable trimming the anomalies went away.  It seems to be resolution dependant on mobile.. looked 100% fine on iPhone5 but had issues on my iPad retina and unity web builds (worst offender).

Compression on pixelart also results in crazy looking problems.. so all atlases have to remain uncompressed.

[Majicpanda]

There will be an attach point system in 2.1 which could work quite well for this. More details here:
https://trello.com/b/UfqlXqXy

Even with this system, it seems my workflow needs to be to have all images made exactly the same with my artist making the "bind point" of all artwork be in the dead center of the image.. that or set a custom anchor on every single image itself in tk2d.  The former method seems a lot easier, but that's a lot of hassle having to create artwork not "equipped" to the model which I understand.. but can be worked around by creating a separate layer with a human head on it in the middle of the screen while working on helmets, etc....

I guess the question is... what's the correct way to use the toolkit if I have 100 helmets, 100 shirts, etc.  Right now it's export in PS at full 40x40, put child GO's on my sprites for equipment points, manually set a weapon in the scene and record the vector3 position of what looks right and for that Race like Ogre, Human, Halfling etc set the "mainhand" vector3 and know to move the sprite to that location.  If I did a custom anchor on every single image then all I would have to do is set the sprite.position to the mainhand.position of each Race, but that is a lot more overhead when importing all 500+ images into the game.

Another workflow is to make a sprite collection per equipment slot but that's a draw call each if i do that, resulting in like 10 DCs just for players and this is targeting mobile.  I only suggest that because I notice you can shift click all and set bind points for the entire sprite collection instantly like that (great feature).

[unikronsoftware]

Can you not fit everything into one big atlas? If you can do that, that might be the best thing to do in terms of draw calls. If not, if you group all parts at the same position, eg. all hats at the same z, all bodys at the same z, etc. then you'll have the same 10 draw calls for 20 characters, as you would 1. 10 draw calls for 20-30 characters isn't too bad. For 1 yes, it would be pretty bad. At the end of the day its just a compromise. If you only have 1 character on screen, and 10 draw calls isn't too bad either.

You have alternatives, but they are all complicated - eg. building up an atlas at runtime.

I haven't got much ideas bout the anchor point stuff - it looks very much like a workflow you've got to sort out between yourself and the artist more than anything else. Whatever works best

[Majicpanda]

If you have 8 "Races" all with custom textures for hair, eyes, skin color... then custom armor that fits each race, and then universal weapons that fit everyone by changing the positioning on the character GameObject, is it more proper to use an atlas per Race at that point to avoid weird draw problems per character? 

If it's per race then that's 2 DCs per character on screen that is a different race than another... 1 for the race and wearable items and 1 for the weapons.  The worst case scenario would be all 9 races on the screen at once resulting in 18 DCs (this is targeting mobile).

If tk2d has zero problems supporting multiple alpha textures stacked on top of each other in a specific Z depth then shouldn't I instead pack all weapons into 1 atlas, all armor in another, and all character data in a third? That would be a max of 3 DCs (more texture memory loaded possibly).

- Character animations and images -> skin color/hair/eyes -> armors -> weapon so 4 DCs per character but if all the characters and animations are in 1 atlas and all customizations are in 1 atlas, all armor etc then it's 4 DCs MAX vs 18.  4 Reduced 16bit 2048 atlases are only 16mb of texture memory so option 2 seems better along as unity and tk2d have no issues doing all this layering from different atlases without any issues.

Sorry if this is design questioning... hopefully it's specific to how unity interacts with tk2d and avoiding any unforseen issues using 2D art stacked on each other.

[unikronsoftware]

Ultimately its down to whatever works best for you. Draw call overhead isn't as bad as it used to be, and 18 draw calls max isn't really that bad, compared to how terrible it used to be.

When stacking up sprites, its best to give them unique z values - pick sensible values so you can use this to get an exact number of draw calls.
If you wanted to group hats together, its sensible to give them all the same z value compared to the bodies.
Obviously if you wanted to group characters together, you'd give each character a unique z value, and then offset each part within the character with a tiny z-offset.