Rodney

I hesitate to post because all I want to say is... "I need that train model!" That is a great looking machine. In my 'Tuckertown' topic and on my blog I have a few posts related to a project where I'm workng with a young boy to realize his story about a train robbery. It's fun and every time I see him I try to have some kind of update for him. I won't ask for the model BUT can I have your kind permission to show him the picture of your train? That will show him the possibilities and definitely make him happy. Perhaps we could even work a deal to have his smaller train... roll through a station directly in front of yours. We'd gladly pay you 25 cents for the image. **(He has a very small budget). His name is Jeremiah. At any rate, you know I'm a huge fan of your work. You still know how to lay down some good spline. Keep it up! **It'd be good for him to learn he has to pay for good quality production assets or build them himself. And thinking along those lines... if you want to sell a copy please name your price and I'll pass that on.

ftp://ftp.hash.com/pub/updates/windows/Am2005/ At this location the most current release should be the AM2005.exe file That should be the last update for 2005 (although that doesn't necessarily mean it is the last update you can run with your CD). The file in the AM2006 folder could run on your CD. That largely depends on when you purchased. Have you tried that one? If you have a v11 CDrom I'd think the very latest you could run would be the exe file in the AM 2005 directory.

Congrats on taking the plunge into 3D printing!

Perhaps you can attach test files in the first post of this topic. I'd like to look at that exact same 'minifig' model you state is problematic in Lumion. I note that 'Model and material variation options', whatever that is, are only available in Lumion Pro. Not sure which version you have.

Agreed. There has to be a middleman program in the mix here. That could be a plugin but it could be a number of other things. Troubleshooting-wise, it is vitally important to make sure what is being taken out of A:M isn't compromised in some way. A:M may be coded to deal gracefully with something but other programs may not. As we are talking about a lossy conversion process, in the process of exporting to OBJ the exporter will just push any problems on down the line. So if normals are facing the wrong way... the exporter can't know that easily (unless it has been programmed specifically to catch those abnormalities. So... should a user decide to export for use in other programs inspection of the model in A:M is most definitely required. There will be errors and omissions at this stage of the process. The middleman software (or exporter) is the next point of failure to examine for obvious reasons. It has to read, interpret and write the data. There will be errors in the transaction and hopefully there will be tests that correct errors and ommissions from the first stage of the process. For instance, the code might be able to 'fix' an inverted normal based on patterns. If everything normal surrounding it facing the other way then turn that sucker around. But most basic exporters very likely do not test for such things so those fixes need to be made before the exporter takes over the process. The importer of the target application works with what it has. The primary way to test success here is to determine what success looks like by using a successful exemplar. All this suggest to me that the problem most likely to resolve the issue is with the model in A:M itself. This has been demonstrated several times in this topic; names with spaces, odd filenames... garbage in garbage out. Focus on the model in A:M first, simplify the tests in order to demonstrate a successful pipeline. Then consider other problems. Lumion apparently cannot edit models. A:M can edit models. Largely what you are already doing now.

Kevin, Are you setting *any* surface color in the Models color setting? As opposed to setting them in groups. If you are... don't do that. Edit your surfaces in the Group settings. Leave the defaults underneath alone. Also before exporting are you doubly checking to make sure all the normals are facing outward? Those two things could very well lead to the results you are experiencing. Jalih, Thanks for the insight into Sitex Air. I posted here in the forum about that suite some time back and took a quick look into it. Sadly, I didn't get much further than that. I'm glad to see you did!

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!