Suggestion: Pose Slider Thumbnails

[pming]

Hiya!

 

I've recently purchased MODO Indi (to give it a serious look see to see if I want to save up to buy a full-on version of MODO), and so far I'm rather impressed. It hasn't crashed once on me, and it's work flow and my brain flow seem to be more or less on the same page. Anyway...

 

...I was fartin' around on their site looking for any of the extra stuff for MODO that I don't get with MODO Indi (mainly the scripting and plugins stuff), and came across something called "ACS 2 Kit" ("Automatic Character Setup 2 Kit"). One thing that instantly popped out at me was just how similar it seemed to be to a lot of the built-in stuff we have here in A:M. One thing in particular made me think, "Hey! That's a cool idea for A:M to implement!". It was, as my title suggestions, a "Thumbnail" of various 'poses' for stuff.... hands, legs, bodies, etc. (re: "Actions" and "Pose Sliders"). I would love to see this in A:M! To be able to make a pose, say, a "strong pointing finger", a "loose pointing finger", a "crooked pointing finger" and a "exaggerated pointing finger"... and have a thumbnail of said 'pose' right there with it.

 

Our "Pose Sliders" and "Actions" could have the ability to store a thumbnail for it. When we needed a "loose pointing finger" we could pop it up, see it right away, and click. If we didn't know exactly what kind of point we wanted, we could see the thumbnails until we saw one that might work... click! Applied to our character via bone naming convention.

 

Anyway, something like that would be pretty cool and useful to me.

 

(MODO ACS thing...: http://www.thefoundry.co.uk/products/modo/kits/acs/ )

 

 

Paul L. Ming

[robcat2075]

It's a good idea, and it has been suggested before.

 

I've discussed it with Steffen before and basically he said that the way A:M uses the operating system to create those pose windows makes it difficult to add images for them.

 

For now, descriptive titles like "loose pointing finger" will have to do.

[robcat2075]

BTW, you may find my "Making Poses" video useful for its coverage of "drag and drop" poses which may suit your hand posing needs better than slider poses.

[Rodney]

Firstly, don't forget to put in a request via A:M Reports. quote/ User requests define the future development of the software /unquote

But if they don't get logged into A:M Reports they don't get properly organized and cataloged.

 

Since you've posted your thoughts here we must assume you want to discuss the merits of the idea and how it might be best implemented in A:M so Ill offer the following by way of looking to see how A:M can get from where it is now to where you envision it to be:

 

Thoughts on what A:M has that is similar to what you describe:

While not quite what you are talking about, a preview image can be associated (embedded actually) into an Action file (and other A:M files) and it might be relatively trivial to have other parts of A:M reference/display that image.

It's too bad Libraries aren't more popular as there is a lot going on there that could be enhanced to the benefit of other internal features.

 

What success might look like:

Being able to assign a preview image to every asset would be useful but all the variations under the hood to get it done must be considered. Optimally, we wouldn't want a system that worked for poses that wasn't extensible to other areas of A:M. In other words we wouldn't want a setup for preview images that was either duplicated but implemented differently in another area of A:M without good reason. quote/ Reuse is the foundation of A:M /unquote

 

So let's go play-by-play for a moment on your suggestions:

Our "Pose Sliders" and "Actions" could have the ability to store a thumbnail for it.

 

 

They do currently (although not quite as robustly as needed for what you envision)

 

The following has a lot going on and while I understand the general flow/goal of the idea this is where the vision would need to be refined into something that could become actual coding:

When we needed a "loose pointing finger" we could pop it up, see it right away, and click. If we didn't know exactly what kind of point we wanted, we could see the thumbnails until we saw one that might work... click! Applied to our character via bone naming convention.

 

 

Constraints/Technicalities

Given that A:M assets currently have the capability of storing a preview image what remains to be considered to get from here to happiness with a full implementation of the suggested feature.

 

Regarding the current implementation of preview images in A:M assets I'll offer the following as observations to consider:

How true these are depends on how code is actually handled on the back side of things.

 

Preview images are embedded.

Discussion

Perhaps an option could be made to allow an external image to be assigned that would over ride the assigned preview image BUT care would have to be given not to circumvent the optimization currently available via preview image optimization.

 

Preview images are Base32 (or is that Base16... I always forget and have to remind myself)

Discussion

Would the preview image data type need to be updated to Base64 or best be left as is and bypassed as necessary to point to an external file?

The longer term vision/associated requirements should drive code change.

For instance, can we anticipate a future user request to have an 'animated preview' of their poses rather than the still imagery?

As this is not practical to implement fully can we allow for that additional enhancement by leaving adequate hooks/space for it in the features code base?

 

Disclaimer: There is something about the current preview format that seems superior to Base64 etc. but I don't know enough about the format or the usage in A:M. It may be that the data is Base16 and simply less abstracted and therefore optimal. In the few attempts I've made to understand the preview image I've seen excellence in it's implementation and would hate to lose that in any newer/updated approach. The upside of Base64 would be that files might more readily have the preview displayed in any web based implementation as Base64 is well estabished and surely optimal for use with HTML5 imagery/video.

 

Preview images are displayed fully so assigning muliple images to an asset would require changing the way preview images are processed in A:M.

Discussion

It is not-quite-true that preview images must be fully displayed although that is the practical aspect as is. In fact, changing the preview size specified does allow part of the preview image to appear in the preview/info panel window. Example: if the preview image data is 97x54 and then the size is changed to 5x5 only the top left corner of that 97x54 image will appear. I haven't really tested this but a naive way of looking at this is that (to the user) this basically magnifies a portion of the preview image... ignoring the remainder that wont be seen in the preview window.

 

Could the preview image be cropped in such a way as to point at only one area of an image?

This sprite-like approach is one way to get access to multiple images for poses where only one underlying image exists.

As with sprite based animation It's could allow for animated previews.

 

Here I have described one way in which the current preview image currently assigned to Projects, Materials, Models, Actions and Choreographies might be extended to include Poses within these settings (embedded or externally).

I have failed to describe how the current preview image would be optimal for use but have suggested it as the optimal approach for implementing a Pose preview

I have attempted to suggest ways around the current constraints of preview image (one image per file so multiple poses have no adequate source from which to fetch their assigned imagery). I do not believe that using external images is optimal but allow for it via suggestion that a line could be added to circumvent/overriide/bypass the embedded preview image. An alternative might be to assign specific images to assets directly

 

Note that I haven't attempted to discuss how Pose based animation might be altered as, unless directly reading available spline data, the preview image would

 

Bottom line: The preview image is a powerful implementation although underutilized in A:M. As such, for that reason alone extending the preview image to Poses would be a good thing. Manipulation of the preview data is tied to several features that were never fully implemented in A:M that were once and would be popular. I'd love to discuss those further but... that'd be a whole other can o' worms.

 

 

...with apologies for the rambling as I attempt to get a wide range of diverse ideas related to the idea into one location.

[Rodney]

I'll add this because it might assist in understanding what I was talking about before with regard to current preview image implementation and changes I was exploring...

 

The preview image container (in any Project, Material, Model, Action, Chor) is as follows:

 

Width=97

Height=97

Version=2

a000

...

a000

Where entries after and the version and before the closing tag is a form of run length encoding of Base16 form

Aside: From 'Hacking A:M', page 322; "A brute force method to generate this image data is to use A:M itself to create the data in a dummy file and then copy and paste the data from the dummy to the desired location."

My suggestion to allow for an external file would take the form of:

Width=97

Height=97

external=image001.png

Version=2

a000

...

a000

If the external file exists the following embedded data would be ignored

An approach that might allow for elements of A:M that are not individual files (Projects, Materials, etc...) might be as follows:

Width=97

Height=97

Pose1=image001.png

Pose1=image001.png

Version=2

a000

...

a000

 

As this is a considerable extension of programming and how A:M handles preview image data I won't speculate further on how such a thing would be best implemented. The issue itself is not how the preview image would be handled but how this might effect the current implementation of Poses themselves. As poses are not independent files but are parts of other files they are handled differently. The solution might be explored by studying an Action that has a single pose contained in it and then extrapolating out from that to multiple poses. This would help us understand how best to approach display of multiple preview images where currently only one such image exists.

 

Again, I do not think it optimal for images to be referred to externally. There are several reasons for this but I won't go into those here. Ask me and I'll be happy to provide more rationale.

Optimally it appears to me that the embedded image would be used by default *unless* the presence of an external file is triggered.

Aside: In this way a preview image could drive a very low rez decal without negating the optional use of a higher resolution image/decal if desired when rendering. For immediate realtime feedback, the lower rez image will always be preferred.

 

Another interesting approach that would work although perhaps less optimally might be allow Preview Image data to be referenced externally. There would be several benefits to this approach as manipulations could be made to either the link or the external data. For instance, an external reference to sequential data:

 

externaldata=pose000.eid (eid meaning external image data or external id... I'm not sure what an appropriate extension might be)

 

Note that as with other A:M implementations of sequential data the trailing zeros would signal to A:M that we are dealing with an image sequence

This image sequence could be animated but would more than likely allow previews to be incremented. Example: Pose1 would link to pose001.eid, Pose2 would link to pose002.eid, etc.

 

As described above futher refinement, animation and assignments might be accessed through cropping (ala spritesheet-type assignment).

In this way external data found in Poses.eid might contain all the previews for all poses but the data would be selected in similar fashion as assigning decals with UVs (but without the hassle of actually assigning UVs).

 

Aside: This might relate to why Hash Inc was reluctant to release the Decal Editor as originally implemented and for some time was one of A:M's best kept secrets. They had much better ideas brewing and the Decal Editor as originally implemented did not fully support the desired/optimal implementation. The good news is that it's much closer to that today.

 

This is a long way of saying that code is so well integrated in A:M that one feature implemented in the code can (and does) contribute to the well being of other features.

I belabor the point of looking deeply into what is there under the hood now in order to suggest that as we move forward we do so not thinking of new features in isolation of each other (or how they are implemented in other programs... although that can and often does provide the spark of useful ideas that leads to even better implementations with spline/patch technology) but in consideration of the greater parts that make up A:M as it is now and what it will be.

 

Thinking this through the realm of macro and micro views isn't easy and a far cry from the utter simplicity of 'I'd like preview images for my poses please', aint it?

 

Get that report into A:M Reports so someday soon we can preview our Poses with imagery!