Rodney

A bit hard to read but nicely done!

That's quite related to this discussion. Someone either accidentally created a useful tool or purposefully did. And besides that, the Amiga was ahead of its time in many areas. I can't recall the specific program I was referencing before but I think it had four different copy/paste options. My first thought was... well, that's a bit confusing. I don't have it installed now but not long ago I had a clipboard extender installed that allowed copies of the clipboard to be saved and recalled later. It was a little bit useful but obviously not enough to keep installed. Yes indeed. Notepad++ asks if I want to update to the changed version of the file. Quite handy.

I'd say the primary benefit of running two or more instances of A:M over use of one is that A:M locks down while rendering which (for all practical purposes) results in no available instances. Of course, the primary solution to that render lock down is to use Netrender but that doesn't negate the fact that other benefits can be derived from running several instances simultaneously. Theoretically, at a minimum, a triad of instances would appear to be optimal. This would have two instances passing data back and forth while the third manages rendering. When one instance renders the other two do not render. This three fold cord then provides a foundation for exploiting parallel processing; because at a minimum there are always two instances available. Running two instances technically won't work because as soon as we hit render... the other instance locks down and has no one else to communicate with (so she delays her work until her friend is no longer rendering). I should add that when I think of 'managed rendering' I'm not necessarily speaking of rendering to disk, which is more fully in the realm of Netrender. An optimal rendering solution would likely be rendering to screen (presumably realtime) which is something Netrender itself can't do... it has no display capability... at least it doesn't without aid. For example, as soon as Netrender renders a frame that frame can be picked up by any program that can display images, including... one or more instances of A:M. And of course that program needs to know where to look for and retrieve the image(s) so if follows that benefits derive from sharing that information (whether within the same program or between several). Since we are speaking of rendering though my one suggestion to improving A:M's rendering would not be to connect to some external renderer but rather to allow the render panel to maximize to full screen with all options logically in view at the same time and with an optional view of some or all of the images rendered. This should make sense especially given the fact that when a single instance of A:M initiates a render it is totally dedicated to rendering.

I understand some of the pitfalls but... even if Read-Only? In considering the use case I identified above I sense that it's not a particularly useful... use case... which is something of a requirement I would think. The thing is with those two instances of A:M that as soon as one updates a model on disk the second instance can update from that model on disk. Almost instantaneously. So, while not quite the same thing it is for practical purposes a near equivalent. I may need to come up with some better use cases.

I believe I've seen some of those numbers (the static references that is) but perhaps it's best not to go into detail on that. Copy/Paste is a valuable tool but it seems to me that many programs don't open that tool to the user. I'm sure there are very good reasons for this approach. That almost sounds like work.... Here might be a reasonable use case to consider (in promoting a more useful approach to copy/paste buffering): Open two instances of A:M. Create a Model with a few splines in one instance of A:M, select some or all of the splines and hit Control C on your keyboard to Copy those splines. Open the other instance of A:M and create a new (empty) model. In the model window hit Control V (Paste) In a (more) perfect world the copied splines *should* appear in the empty Model. Currently, this doesn't work. If I understand correctly this might be because each instance of A:M creates its own set of pointers which don't match so copy/paste process fails to recognize it as a legitimate option. The question I might have is what it would take to make these two instances of A:M talk to each other, share data in memory, etc. Disclaimer: Obviously one way to get the splines into the second model would be to save to disk in the first instance and then open or import that model into the second instance. But the point of the use case would be to use shared memory or some clipboard style copy/paste buffer to quickly move data from one place to another.

Yes, that makes sense. That would at least be humanly readable. Assuming A:M would store pointers to data structures this makes we wonder if these pointers could be saved to disk for loading later. Of course a tag would need to specify the type that would be encountered in order to avoid data being pasted into incompatible places. This makes me think that one of the reasons a copy/paste might fail (in A:M) is that code checks to make sure the proper pointers are present in order to allow the data to be pasted. For instance, if copying a group of splines then opening a material and trying to paste that data into a given field the paste would fail because the pointers indicate incompatibility. This would be true even if the data copied would otherwise be compatible... say copying a value of 100 from one field of property data into another field. Note that in most cases this particular copy/paste (numbers in any property field) will work for copy/paste because the pointer is likely identifying the data as an integer or general value that can be pasted anywhere an integer is designated. The code may or may not specify an allowable range or type (percentage, range of values, etc.) I suppose one could consider any given Model, Project, Action, Material, etc. as the output of a successful 'copy' operation. So here is where we can get Tyson's suggested XML formatting. This data can then be loaded into the program again as a copy of that state. Thinking in these terms one option might be to have a content sensitive option to 'Copy to ' at every stage of the operation where the location the data is saved is user defined.* For example, when modeling a head/face a group of Control Points is selected, Right Click and 'Copy to Model' appears as an option. Selecting this option would then bring up a dialog box prompting user for location of file to be saved. The file would then contain only those elements that where copied just before saving. How is this different that what we currently have? We'd have to do several steps to isolate the thing that will be copied in order for it alone to be saved. Yes... I am over thinking this. *Some of these exist already or have plugins that more or less do the same thing. I'll add this also: A spline section in isolation of course would not necessarily be the same as that connected to other splines. For example: if two CPs are copied from a three CP spline the three CP spline might have a curvature that will not be preserved as the two CP 'version' would be a spline between those two points... a straight line. Similarly, there is no preserving consideration for copying individual CPs such as the first and last CPs on a spline where the middle CP is not copied. I suspect that A:M does actually copy those CPs but when pasting them back into the Model the CPs fail to persist because they aren't connected to any spline and A:M will only recognize CPs attached to a spline.

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.