Rodney

Living the dream Tore. You make it look fun!

A:M's materials would need to be baked into a decal image as things currently stand. To 'connect' materials in A:M and some other program equivalents would need to be found. The latest PBR approach is much closer to A:M's material approach in that under the hood its the same material. So... if a direct equivalency is needed then similarly to Robert's comparison of text file differences a similar approach could be used to compare 'empty' materials in whatever two programs were being used. This basic material would then make the transfer from one program to another but the additional materials would be replaced on a material by material basis. A utility could be created that would automate assignments so that materials in one program would automatically change materials in the other. The idea would be to create two directories, one for each program and the utility would manage the equivalencies... changing them as needed based on user input. I may have to test that idea on a simpler problem. The basic idea is that the middleman utility doesn't particular care what the file is, what format or even the content.. It just needs to know what the user considers to be equivalent.

LOL How many forums do you frequent that allow uploading of 3DS files? Silly human. As Robert suggests any zip file can be uploaded.

When exporting from many applications there is an option to create binary or ascii output. The binary won't be human readable. This may not be a showstopper because that same file can be converted again but... it is getting filtered through a converter which has to make assumptions and equivalencies which will have a varying degree of accuracy depending on the tool used to define what accuracy is. I note that MeshLab... last official update released back in Dec 2016 has had 210 updates since that release so.. if you or someone you know can build that it will contain a lot of fixes designed to meet more current needs. MeshLab does a pretty decent job of converting. (I mention this here because Meshlab can get resolve a lot of problems when they are encountered).

Hmmm... I'll have to check. Perhaps that was with baked textures or a derivative from a subsequent conversion. Some formats definitely won't work... for instance, I don't think I've every seen an OBJ file reference an .EXR file. Doesn't mean it couldn't if the receiving program will recognize that. I think somewhere else in the forum I linked to the OBJ spec. Way back when I was delving into the format and learned a lot about it. Things I've largely forgot because I didn't have much need. Here's a link that contains some useful information: http://www.martinreddy.net/gfx/3d/OBJ.spec And another: https://www.cs.utah.edu/~boulos/cs3505/obj_spec.pdf P.S. Out topic has changed so perhaps it needs to be retitled or branched into another topic?

Just to rule it out... with regard to OBJ... Many programs will fail to attach images because the image is of a given format. For instance, some programs (I think Sketchfab) will not recognize .bmp. Well... bmp is the primary image format used in exported OBJ from A:M. So... problem. The fix there is to open the .MTL file and change the referenced name to a suitable image format (like .jpg) and then... Convert the .bmp to .jpg. Then Sketchfab will like it. A lot can go wrong with any importer or exporter but in all cases they only will do what someone has directed. If the problem is known. It can be fixed.

Ah yes, that's the tick-et! Thanks for refreshing the memory. From a previous discussion that quoted from an (unidentified) previous discussion:

That's one of those silent animations that you swear you can really hear. Zrrrrrp Zrrrrp.

Which is why I suggest augmenting A:M with other tools. Especially those tools that A:M has never had and those we shouldn't expect to see. Two things in particular come to mind that specifically fit that category... color management and video editing. Some of that can be done in the course of standard operating procedure directly in A:M but A:M is not specifically designed for that. Unless someone really surprises me A:M is never going to be a color management system. To suggest anything specific I'd have to know more about the specific frustrations and obstacles you are facing. I do know that a ton of things can be done in post... compositing and such... so that alone can save many a frustration. Who here has exported out a file from A:M and lit it in Keyshot? Probably not many because solutions don't always come cheap. Still, that kind of solution may be exactly what is required to compete. I suppose that may depend on who it is we compete with.

Here's the CNET article relating to this: https://www.cnet.com/news/facebook-redefines-time-with-open-source-flicks And a similar article from Techcrunch: https://techcrunch.com/2018/01/22/facebook-invented-a-new-time-unit-called-the-flick-and-its-truly-amazing/ From that article: And here's an article that gives some credit to a VR engineer from Facebook: https://www.cnbc.com/2018/01/22/facebook-group-invents-flick-to-measure-video-frame-rates.html The guy who invented it left the company months before it was approved to be released to the open source developer community. Christopher Horvath has this to say about the news: Added: Meethinks this is very timely with the release of the AV1 video format.

Kevin, It just occurred to me that if you are wanting to work in a more controllable color environment there are free solutions available to do just that and they can work with A:M in that the initial imagery is created in A:M but any subsequent change is managed in dedicated locations optimized for that work. Specifically I am talking about Blackmagic's Fusion and Davinci Resolve. Resolve was first and foremost a Color Management software before the recent addition of Non Linear Editing tools was added and of course it was the industry standard. So Resolve is highly recommended for such tasks. Fusion is being more fully integrated with Resolve with every update but even now it has most of the basic tools for storing and maintaining accurate color... it doesn't have all the management stuff... because that's what Davinci is for... but even there a lot can be used back and forth between the two applications. (There are some excellent videos that cover that) I'm attaching a screen shot of some of the color spaces available just via Open Color IO (OCIO) which is significant. The primary task (besides just learning color management) then falls to how best to move through A:M to achieve the ideal color and lighting output. But even there Fusion and Davinci should be able to assist because of how Fusion can be used to manipulate composited images and relight scenes. If lighting and color management and better control is desired you should definitely check Fusion and Davinci out. Because Blackmagic is first and foremost a real world camera company they have a solid grasp on the technology and a vested interest in being accurate.

I haven't read all the comments to that video but I did see this from a guy named Noah Hornberger. The underlying idea here is that 'realism' is rarely the target... unless you are trying to match real with unreal and even there we may run into problems because the real may appear unreal. The target is more often than not one that someone will target through an artistic filter as they say... that's the look I want! As for lighting in A:M the first an perhaps most important decision we can make when concerning ourselves with higher dynamic range and contrasts is to make sure we are using the EXR image format as it is the only one that will store that data. I'm no expert but I'd say Targa would be the next best format. Importantly, that doesn't need to be the end of the pipeline... we can temporarily use EXR to gain the advantage of linear color workflow and high dyncamic range and then we can convert to other formats where we target specific looks artistically.

What is larger than a nanosecond but shorter than a second? If Facebook (and presumably others) have their way it is a 'flick'. A flick is defined as: 1 flick = 1/705600000 second Somewhat usefully (mathematically) a flick can "in integer quantities exactly represent a single frame duration for 24hz, 25hz, 30hz, 48hz, 50hz, 60hz, 90hz, 100hz, 120hz, and also 1/1000 divisions of each." This helps with conversions of frequencies and image/audio sync. One potentially useful bit of information I saw outlined in the write up on flicks is this on the NTSC standard of 29.97 frames per second... something I have always thought was painful to consider: I am rather pleased to see the underlying standard in that equation includes 24 fps but as oulined above it syncs well with 24, 25, 30, 48, 50, 60, 90, 100, 120 etc.. I can't help but think some old time animators might appreciate the use of the term flick as well. (as they were accustomed to flicking (and flipping**) sheets of paper to test their animation). C++ code has been open sourced and is available on github at: https://github.com/OculusVR/Flicks According to the write up on github: So an accurate resolution of time was deemed necessary enough that they are releasing and promoting the spec in hope of universal adoption. As for usage of the code itself: This is an odd thought but... I was under the impression that A:M already used 'flics'. Hmmmm... **I wonder if we might eventually see a unit of time called a flip. Sure, why not. But come to think of it a flip is likely a unit of measurement like 0/1, 1/0 and 0/0 that for all intents and purposes is undefined until such a time as another term is used to define it. 0/0 is straightforward enough. That's some undetermined percentage of 1.

I thought I'd give Sketchfab a test to see if the textures work. Initially it didn't but then... it did. https://sketchfab.com/models/bf165f2fccf149cda73fa2d7d06bccb4

Me too! That's why I'm helping to create it. The author, a young boy about 8 years old, has a knack for telling jokes so I'm looking to see how we can incorporate his penchant for humor and that general style into this particular story. This, and other layering in of details by other kids makes for fun and engaging 'dailies'. Although I suppose at this stage those could be called 'weeklies'. Hmmmm... I should incorporate that jargon into the mix but call them 'weaklies'. Then at those sessions we run them a bit like Disney/PIXAR storyboarding sessions where we try to extract the strengths and weaknesses (as they are seen at that exact moment) and plus up the story.

Thanks David! Here's a quick addition of Bearded Man's partner... Tall Man. I got a little lazy with this guy and as of right now he's missing some splines that are hidden from the camera such as the back of his head.

Go bear go!

Thought I'd attempt to translate the Bearded Man (one of the train robbers) into 3D. Interestingly, the white wheels of the train don't look as bad with the right lighting... Disclaimer! Bearded man NOT to scale. Edit: Posted a second image closer to scale.

I think you are headed in the right direction. The differences in character (body type) really makes a difference. I like!

It'd be great to have you splining with us again Curtis!

It's great to see you in your own Special Topic. You've been fielding some highly entertaining work for a long time now. Here's looking forward to lots and lots more!

It seems more than a few people were taken by surprise when a few weeks ago Apple joined the Alliance for Open Media. They were the big holdout. CNET article (this has some info related to the AV1 format too): https://www.cnet.com/news/apple-online-video-compression-av1/ The first article I saw: https://bitmovin.com/apple-joins-av1-codec-consortium/?utm_source=bitmovin_newsletter&utm_medium=email

hehe! Nice! Silver never looked better.

Looks great Tore! High quality.

Here might be an example... A project consists of one Sphere and two Actions. The first Action controls up/down motion. The second Action controls distance traveled. The Sphere is placed In the Chor. Both Actions are dropped onto the Sphere (and made to overlap... because the second will generally follow after the first when drag/dropped). Both Blend modes are then set to Add. For fun have the up/down Action repeat three or four times. The entire animation occurs over 1 second (or 3 seconds if preferred). The Chor Action is baked. The resulting Baked Action is exported as an Action. Now the Action can be brought back in and used as the basis for more complex and layered action. But... Before proceeding a pass needs to be made to simplify the new Action because it contains too many keyframes and lacks optimized hard and smooth transitions. That's a basic Bouncing Ball setup that initiates from a series of simple overloaded Actions where it would be nice to reduce, round or average the values in all of the resulting channels and... to limit the number of keyframes for easier editing.