Question about Keypoint and Origin in Shapefusion

[Spurious Interrupt]

Hello again.


So I'm considering doing some more shapes work when I have time this term(+ finishing 2000's project if he's still interested), and I've been playing around with shapefusion for a bit.

I'm curious about the Keypoint and Origin marks in the frames section, as no matter how much I change them, nothing seems to change. The only thing in that section that seems to change anything is scale. I know I'm editing the section (True color) that my game is seeing, as the changes I make to the bitmap itself show up, but the changes to the origin don't.

I vaguely recall something about this being a glitch from when we were working on the HD sprites, but I'm not sure. If that is the case (that Keypoint and Origin are non-functional), does this mean the best course of action would be to edit the image itself to match the default Keypoint and Origin?

Thanks for your time.

[Zott]

I have had no trouble when editing Keypoints for 8-bit sequences in ShapesFusion. I can imagine this may have something to do with using True Color Shapes.

Would you be willing to show a snapshot of how you have the Keypoint setup to help troubleshoot the issue?

Otherwise, you could try using a 8-bit Shapesfusion sequence with modified keypoint as a test. The 8-bit ShapesFusion graphics could then be replaced with True Color versions with a mml/plugin if need be.

I would recommend not padding the images to try and fit them around the keypoint. This makes the file size unnecessarily larger.

[Spurious Interrupt]

I have had no trouble when editing Keypoints for 8-bit sequences in ShapesFusion. I can imagine this may have something to do with using True Color Shapes.

I think you're probably right, that sounds really familiar to the issue 2000 ran into.

Would you be willing to show a snapshot of how you have the Keypoint setup to help troubleshoot the issue?

Here's a video. Don't mind the lack of transparency and low resolution; this was just a test to see if I could get anything to show up.

The video shows how no matter how ridiculously I change it, nothing changes.

Otherwise, you could try using a 8-bit Shapesfusion sequence with modified keypoint as a test. The 8-bit ShapesFusion graphics could then be replaced with True Color versions with a mml/plugin if need be.

How do I tell the game to use the 8-bit graphics? I don't see anything that (intuitively) appears to be that option in the settings.

I would recommend not padding the images to try and fit them around the keypoint. This makes the file size unnecessarily larger.

Noted. If I do go this route, I'll be making the images myself, so I don't think I'll need to do any "padding" if I put enough effort into making/matching the new images beforehand.

[Zott]

Nothing seems to be immediately jumping out at me as egregious.

I tried adjusting the origin in Shapesfusion on both the True Color and 8-bit sequences, and there was no visible change in-game. However, it is possible to modify the position of weapons in the physics file (also using Shapesfusion). Since the origin of monsters and other objects are not changed via physics, it leads me to believe that Origin and Keypoint for weapons in the shapes file are not used. (Also note where the missile launcher origin is placed relative to where it appears on screen during gameplay.)

Perhaps one of the developers can shed more light on that.

Otherwise, my suggestion is: Modify the shapes as needed, change their on-screen location using physics.

[Spurious Interrupt]

Otherwise, my suggestion is: Modify the shapes as needed, change their on-screen location using physics.

You mean with height and idle?

And one additional question; while I assume that altering certain sections of the physics file (such as running or actual weapon performance) may cause OOS in netgames, would this section be fine?

[Hopper]

Looks to me like Zott is correct. Only the overall height and width are used for weapons in hand: the origin comes from the physics instead. All of the variables in the "Height and Idle" section are only used for rendering, so they would not cause OOS in netgames, but of course embedded physics would interfere with a custom origin setting. So, this is fine for full scenarios, but plugin replacements would need to work with the default origins by padding the images appropriately.

Zott mentioned that padding can grow the file size, but if you're building an HD plugin where all the images will be replaced with textures, you can add blank images of appropriate size and the Shapes patch will be much smaller. Freeverse used this technique in the Durandal XBLA port, since the actual Shapes bitmaps are never seen.

FYI, while Origin is important for most shapes except the weapons-in-hand and interface collections, Keypoint is only ever used for player legs. You can ignore it unless you're tweaking the player sprites.

[Spurious Interrupt]

Thanks for the info!

One other ShapeFusion question, just to see if anyone's run into it before:

I've added in a few bitmaps now, and they've worked fine. However, as soon as I changed the scale from whatever it was when I first copied them in, they disappeared in-game. When I changed it back to what it was, they were still gone. When I copied in the image a second time, with the frame set at the scale the first one originally worked at, it was still invisible.

Is some aspect of the scaling function permanent, or is there something else I activated by scaling it? Because I'm not seeing the logic behind what's happening otherwise.

[Spurious Interrupt]

After playing around with it some more, as best as I can tell, the "scale factor" doesn't work on anything except the standard images. Everything else I put in becomes invisible when I mess with it, and in a way that I can't fix by changing it back. It does work with the standard images though.

It also seems that it selects the origin not to be at definite x-y points, but at a definite point relative to the edges of the picture. This is useful, as it means I don't need to match the images pixel-for-pixel (just get the ratios moderately close).

For example, take this firing sequence. The image itself is about 8 times the size (by pixels) of the normal BMPs (something I was trying when I still thought scaling worked), but it's centered more or less correctly (as opposed to being centered in the upper-left corner as the "origin" point would imply).
http://www.youtube.com/watch?v=9XlVZmQ6IeU

This also means I'll just have to cut out more of the white (well, blue) area to enlarge it (yes I know the shading is bad; rest assured I'll ask you all for aesthetic feedback when that's all it's down to).

Also, if it helps future questions, I'm actually not using any editor between my rendering program (Photoview 360 in SolidWorks) and Shapefusion. I just took the exact color of what Marathon seems to think is transparent (got it by exporting some of the images via Shapefusion) and made that the background in SolidWorks.

So I guess I answered my own question, but I'd still be interested to know why scaling works on the stock images, but not on others (which is different than the origin editor, which doesn't work on either).

[Zott]

I ran a quick test with a 'smiley dude'. (Smiley Dude attached )

I replaced the frame for the idle fist with Smiley Dude imported into ShapesFusion.
Default Scale Factor was 7.
In-Game, smiley dude appeared in hand about the same size as the fist.
Changed Scale factor to 8.
Smiley Dude became Huge!
Changed Scale Factor to 7.
Smiley Dude different than previous scale factor of 7...much bigger than originally
Smiley Dude changed to scale factor of 3
Matches the initial testing where I didn't change the default value.

In conclusion, the scale factor on a custom sprite, for a True Color(Only one tested) Weapon appears to be working. Is it consistent? No, but it is working...
[Ignore the changes in Origin on the pictures below, as previously discussed they do nothing]

[Spurious Interrupt]

Cool, that's consistent with what happened with mine. I'd guess it grew so large that either the system decided not to render it, or transparency was the only thing on-screen.

[Spurious Interrupt]

Is there a file-size/pizel-size limit I should be aware of as I make these images? For the moment, I'm editing them directly into the Shapes file.

[Spurious Interrupt]

Here's my first "full" sequence.

What do you guys think? I think it might be a little bright (that could be because I had to make it bright to counteract a transparency issue that kept coming up, though I might be able to get around that a different way now).

My main goal was to animate it in a way so that it never went in front of the cross-hairs (as opposed to the stock images that all but block the screen during reloads).