Rodney

This is a bit of an odd question but I'ma gonna ask it anyways... When a person using a program such as A:M performs a copy/paste I must assume that: Data selected is stored in a copy/paste buffer That data is not stored in the operating system's clipboard (i.e. the operating system's standard copy/paste buffer usually used for text and images). I will further assume that if we could see the data we might only see the bits or the bytes or... perhaps the exact data that was selected at the time (numbers, text, etc). I realize this can get complex when we step away from standard text and image data for those times when a spline is selected and copied... or a selection of Control Points. Still, I cannot help but think this data useful if the formatting of that data were a known thing. So a few general questions might be: What would we see if we could see the data in the buffer? What benefit (or problems) might arise if we could access that data (for pasting generally into places that may not be specifically designed for such)? How can we access that copied data? Why is it the usual practice for most/many programs to use a separate paste buffer rather than the OS clipboard/paste buffer (Note that I assume several things may be true here but am more interested in answers from those knowledgeable of such things)? What will I do with this information? At this point I'm not sure but I am trying to wrap my head around something of a space where diverse programs can talk to each other and share data that would otherwise not be available. Thanks in advance for your time and for any information and insights you can share. Added: I have seen a few programs that offer a choice of how to copy data. For instance, one might right click and select Copy to Clipboard or Copy to Memory, although the latter would very likely have a more appropriate name. Shortcut keys then could be assigned to those menu items if such was desired or needed.

It'd be good either way but... feel free to open a new one.

Yes. Sorry.... very odd. I thought I was posting there.

Interesting. I will guess that some folks will be very interested in the workflow that gets you from A::M into C4D to Octane.

Here's a quickly converted Y WIng from OBJ format. The splinage is dense and has been peaked rather than repaired to get straight lines where there obviously should be straight lines. If primary shapes were replaced by lathed shapes the patch count and file size would drop considerably. I also removed the decals from the MDL because the original's didn't match up either. There are a few missing pieces that could be emplaced through duplication of other parts. Credit where credit due: This model originally posted on internet (in OBJ format) by Glenn Campbell. I'm not sure if that is also who modeled it. YFight_part.mdl

At a guess I'd say... inverted normals?

There is a folder of Star Wars characters and props on the Extra DVD but... at present I've misplaced my Extra DVD (and the prototypes that preceded them). Perhaps someone with the DVD can post them in the A:M Exchange forum. The following X Wing is posted in the A:M Exchange forum: Here's a direct link to the ZIP file: LINK Here are some older (classic?) models by Dan Olsson: LINK ...and don't forget that A:M imports OBJ files quite well and there are lots of Star Wars models in that file format out on the web.

Welcome to the forum Tim! You've definitely come to the right place. Over the years there have been many who have contributed their Star Wars models to the forum and while some of those models might show their age I'd say all might be a good starting point for you to work from even if they are only used as temporary stand-ins until more ideal models can be made. Live long and produce and may the Forces spline with you!

Thank you kindly. She may not look it but she's the leader of an elite team of time travelers that go about fixing things in history that get mixed up. It's lucky for us she's on the job because... not sure if anyone has noticed... things are pretty messed up. (She's not quite as dainty/cute as in my original drawings so that part of her transition to 3D is still a work in progress.... and in my initial take she's a tad more blue/green than radioactive green) Here an initial look with really really REALLY short hair (I think this was one of the first tries out of the renderer):

Had a great time in the ol' Live Answer realm today. I didn't post this during the session but as a follow up here's an example of a model I'm currently using to test hair. Finding a lazy way to control hair length is my underlying goal but I know that sometimes the work just has to be done. As Robert mentioned during the session, an image map (specifically a decal) driving the length property is likely to be optimal. I don't know why I always stubbornly resist dong things the 'right way'. Instead of pushing forward with a decal I find myself manually adjusting and wishing I could use materials or patch images instead. In the attached the hair near the mouth would need to be considerably shorter in order to show that there is indeed a mouth hiding under there. I've included the model/project but it isn't much to look at. Kat.prj

I'm sure there are utilities that allow for this but... There is a way to get standard icons (.ico files) to appear with the files but it's by way of a hack. Specifically, if one wanted to go through the trouble of doing this they could set up two folders with the first being the original files and the second being shortcuts to those files. (They could be in the same directory also) Shortcuts can have their icons modified via Properties (i.e. there is a 'change icon' button). You would then use a program/utility such as Irfanview to generate the .ico files from an image and assign it to the file. Edit: This makes me think that the shortcut icon/pointer could be hacked together much more automagically. Hmmmmmm... I'll have to look into that. Automation-wise shortcuts can be made by selecting an entire directory full of files, right clicking and selecting 'Create Shortcut'. The tedious part would be creating and assigning the icons. An alternative approach that works with HTML would be to include a preview image (usually the same one that was used to generate the file's preview image) in the folder. This image usually should have the same name as the file itself. (example: building001.mdl... building001.png). The HTML page would then point to the png image as well as provide a link to the model. If the embedded preview image was Base64 javascript (or php code) could be used to pull out the image out of the file into any modern browser. Easy to say of course... harder to code.

I found some of the pertinent info regarding the image format. Yves Poissant is/was the expert that shared this info... He said:

No. But... The image data of the icon is such that a shell extension could likely be written that would accomplish that but.. that isn't very likely. I periodically forget what the image data format is. I think it is Base16. I've often thought of putting in a feature request to update that format to base 64 because that is more readily accessible by browsers but... even then this wouldn't allow the operating system to display the icons without some form of shell extension written to allow for that.

I don't think I've ever seen Oliver's youtube tutorials for A:M. Where the heck have I been? Here's one where he starts to set up a book with turning pages based on Kevin Detwiler and Robert Holmen's example posted here in the forum. Note that this is a multi-part tutorial (in 5 parts) and is Tutorial 40 in the series. xhttps://www.youtube.com/watch?v=tfgDqGe9GSk Here's the collecton: xhttps://www.youtube.com/playlist?list=PLwmsT_c4rTUaJZP7RPzs1i7tdY-LuwKgn He states: Thanks Oliver!

Don't forget that an added level of complexity is that the wheel/tube itself is hollow (even before considering the holes), so two tubes with holes (one inside the other) then connected... I've added an (ugly!) example of the outer/inner tubes of the wheel. It very obviously has a lot fewer holes than the reference image. Following Rodger's more meticulous approach would resolve the ugliness. UglyHollowWheel.mdl

Congratulations! Well deserved. Did you get to go to that and see it presented with an audience?

The first thing I'd do (troubleshooting-wise) would be to copy over an older image IO file from a previous installation (one that works in that older release). It may be that file got corrupted somehow. That very likely won't work but It's worth a shot. On Windows those IO files are in the C:\Program Files\Hash Inc\v18.0\ImageIOS directory. They have an IIO extension on windows with the file format as their name. Not sure what they are named on the Mac platform.

Nice. And he fits well in the realistic style you've got for the streetcar too!

Nicely done Gerry.

Yes, along those same lines we can set up two materials (copy out a duplicate of the original and bring it back in under a new name) and then copy the settings over to the new material. Of course when the material get complex this becomes unrealistic. I needed a basic shape to test some of this out so I made a quick mushroom and added a very basic Perlin material. The only material in this rendering is that basic material tweaked in each instance (three instances) in the Model. It would be handy to be able to save out those tweaked materials for reuse.

No. That would indeed be easy. I suppose you could say I'm looking for a way to save/export a moment in the life of a material that changes over time for reuse later. It's hard to believe I've never run up against this before. The method I thought was going to work was to rename the instance and then drag/drop it back into the Materials listing in the PWS (which surprise suprise... actually works!). The problem there is that this looks like it shouldn't be something we can do because the new material isn't actually a new material but has drivers that point to the original. For a moment when I saw the new material there I thought I could save it out as if it were a new material but unlike regular materials the option to Save isn't available.

Look for those in the Toons Render option in the Render Panel. You'll want to toggle on Override Lines.

Oooo.... oooo..... I think I've got it. For a second there I was really wondering how the heck I could get it done. The answer isn't exactly straightforward but is easy once we know how. Let me see if I can make this an opportunity to share a video. Gah! So close but nope.

I seem to recall a simplemethod for doing this... Perhaps someone can set me on the right path. I have a material that is saved as two different materials. The main difference between the two is that one is set with displacement and the other is for color. Both materials can then be applied to a group to better control the texture. That's not part of the problem... just a little background/setup. I dropped the color material onto a different group in the model and tweaked the settings. I like the changes so want to keep that new material. The issue is how to save/export that material as a new material. If I stepped away from the computer for awhile the answer might come to me but for now I'm at a loss. Am I missing something really basic? I know that I can grab the material settings from out of the text file Edit: Editing/extracting the data from Project/Chor/Action textfile doesn't appear to be an option either because the material tweaks reference the original material. Hmmm....

Very nice Chris, and very well executed. Also, an excellent theme/story for graduate student work. There may not be a lot of A:M users in China but I'm glad to know one.