Этот сайт лучше всего просматривать в современном браузере с включённым JavaScript.

Question regarding asset integration

Majicpanda

Harald написал
Regarding equipping items and different directions, it will not make much of a difference: you would then equip the goldensword-up attachment at your weapon-up slot and your goldensword-right at your weapon-right slot, while the respectively playing animation will show and hide the respective attachments. You could also see each equipment item as a skin, attaching multiple attachment images at multiple slots, like trousers are also a skin in the Mix and Match example Spine project. You can check out the code in spine-unity example scene Spine Examples/Other Examples/Mix and Match Skins.

This actually makes a lot of sense. I was concerned of the performance problem of constantly changing attachments every direction change, but you're suggesting to run the equip item logic over all slots any equip change and then let the Spine animation itself dictate the slot visibility. Thanks for all the insight, we will see what kind of damage we can do 😉

Harald

Glad to hear it helped, thanks for getting back to us. 🙂

Majicpanda

This new process worked perfectly for being able to use the individually packed atlases, but the rotational info is not in the exported Weapons atlas like the example in the project.

Weapons.png
size:1024,256
pma:true
Weapons/axe
bounds:2,2,500,250
Weapons/sword
bounds:504,2,500,250

I'm using the AtlasRegionAttacher to test the idea out and the weapons are pointed straight along the bone instead of how I positioned and rotated them in the Spine project.

Harald

Majicpanda написал
but the rotational info is not in the exported Weapons atlas like the example in the project.
..
I'm using the AtlasRegionAttacher to test the idea out and the weapons are pointed straight along the bone instead of how I positioned and rotated them in the Spine project.

I'm not sure I understand your question correctly. Please note that the atlas only contains packing rotation of 90, 180 and 270 degrees to fit the attachment better into the available atlas space. Skeleton attachment rotation is not stored in the atlas. It cannot be stored there, since you can use the same attachment (e.g. a dagger attachment) multiple times at a skeleton, with each instance rotated differently to e.g. position one dagger attachment in a mouth, one in each hand and one at a belt.

The Skeleton has each attachment rotation stored at the parent Slot. So when exporting your skeleton, your individual attachment rotations are exported in the .json or .skel.bytes file.

Please let me know if I misunderstood your question.

Majicpanda

Harald написал
Majicpanda написал
but the rotational info is not in the exported Weapons atlas like the example in the project.
..
I'm using the AtlasRegionAttacher to test the idea out and the weapons are pointed straight along the bone instead of how I positioned and rotated them in the Spine project.

I'm not sure I understand your question correctly. Please note that the atlas only contains packing rotation of 90, 180 and 270 degrees to fit the attachment better into the available atlas space. Skeleton attachment rotation is not stored in the atlas. It cannot be stored there, since you can use the same attachment (e.g. a dagger attachment) multiple times at a skeleton, with each instance rotated differently to e.g. position one dagger attachment in a mouth, one in each hand and one at a belt.

The Skeleton has each attachment rotation stored at the parent Slot. So when exporting your skeleton, your individual attachment rotations are exported in the .json or .skel.bytes file.

Please let me know if I misunderstood your question.

Wow my mistake then... we were going to use spine a few years ago for a project that got too big and I recall simply dragging everything to a slot, rotating and then exporting and it all just worked. I guess the actual workflow is every item needs to be drawn on the X axis pointing right but pivot wise that's something to figure out also since that info is not stored? I assumed I had to drag every item as an attachment to the proper slots and then rotate then move them all so the handle of an axe etc pivot was set.

Harald

Majicpanda написал
I guess the actual workflow is every item needs to be drawn on the X axis pointing right but pivot wise that's something to figure out also since that info is not stored?

Pivot info is also stored at the skeleton, yes.

One easy solution for perfect rotation and pivot offet would be to have one larger attachment image size that fits any future attachments and then let whitespace stripping do the job of removing the unused transparent space, as described a few postings above:

Harald написал
you could e.g. use a single larger attachment image size with lots of whitespace large enough for all kinds of ear or weapon types, and then let the Atlas export setting Strip whitespace X/Y remove the unnecessary transparent border at each image. This way every image is already positioned exactly where you want it to, without adjusting any pivots.

Majicpanda

I finally understood the 0,0 origin for weapon attachments and those are working great with the custom atlas packing, but when moving to all the different pieces of equipment like each foot, leg, chest, arms, etc I'm not quite understanding how all of that equipment will work. It would be quite cumbersome of a flow not to be able to have our artist draw directly onto the skeleton in the PSD or deal with figuring out the pivot of every single slot required to then draw each piece into a separate PSD with 0,0 origin. Is this what's required to make a robust equipment system?

Harald

Admittedly I'm not completely familiar with how you can setup PSD layers for export, but what needs to be ensured would be the following:

You artist shall draw in the real position as usual, no need to move everything to (0,0).
Each exchangeable layer (e.g. each helmet) bounds need to be setup so that it is "sliced" with the exact same larger bounds that fits all helmets.

So your artist would e.g. draw both a large horned helmet and baseball cap in-place, then setup export layer bounds accordingly so that both helmets fit into it. This will result in unnecessary whitespace around the helmets, which can then be removed by whitespace stripping upon texture packing. This way origins don't need to be (0, 0), they just need to be the same.

Unfortunately I'm not capable of telling you how to setup Photoshop accordingly to "slice" the layers accordingly upon export, I'm just a mere programmer :nerd:. We will find help however in case this is a problem!

Majicpanda

Passed this info along to the artist... mere programmer myself here also 😃 I really appreciate the time taken to get this process ironed out. I almost feel the Spine workflow will be one of our top 3 systems in the entire game at this point, lol.

Ultimately, do you feel all of this is absolutely necessary or what is the draw back compared to letting spine spit out many, many sheets of atlases and just use basic slot swap API?

The biggest thing we wanted to support was modding in the future which will require static atlases players can draw over, but if it becomes too cumbersome to get all of this working quickly we would need to skip that for now and just get a prototype working. It sounds like maybe the export script for Photoshop may not natively support the slices idea at the moment?

Harald

Majicpanda написал
Ultimately, do you feel all of this is absolutely necessary or what is the draw back compared to letting spine spit out many, many sheets of atlases and just use basic slot swap API?

It all depends. If you want to support modding, you will need to provide some dynamic loading mechanism to load the custom modified skins, unless you want the modder to overwrite your existing assets. If you want to support dynamic loading, you need to organize everything so that you know what assets need loading, one way would be to group atlases by skins. This would make things easy to add new skins as a single atlas texture package, e.g. to add a custom "robocop knight" skin.

The more important point however is that with unified origins you can easily yourself add skin packages as updates, without having to replace the main skeleton all the time. Having a unified origin for e.g. all weapons would mostly save a lot of additional work. Nevertheless, you can also write a custom offset script and store pivot offsets for each attachment and then offset the attachments programmatically if you prefer that.

Majicpanda

Sorry to necro this again.. we finally got around to art side of prototyping this and I misunderstood thinking you could key frame SLOT visibility... but this does not appear possible.

How do you key frame attachment visibility if you are using a programmed equipment system to set attachments per slot? I thought we could make a Torso_Front / Torso_Back slot and when walking down vs up it would simply toggle that SLOT visible with a key framed slot.

Harald

Use Skins.

« Предыдущая страница