Project Messiah 6

Become a member of the CGSociety

Connect, Share, and Learn with our Large Growing CG Art Community. It's Free!

Thread Tools Display Modes
  04 April 2013
No word about the in version 5 broken file formats. There was no correct working one. So my guess is that they are still not fixed and are still buggy up to useless.
  04 April 2013
is it me or is that 64bit png image (new -> rendering -> 64bit png) actually clamped in photoshop? While they say its not?
  04 April 2013
Originally Posted by Tiles: No word about the in version 5 broken file formats. There was no correct working one. So my guess is that they are still not fixed and are still buggy up to useless.
What file format are you talking about exactly?

  04 April 2013
All of them. There`s not a single not flawed format in the im- and export.

Import: Obj comes in without material settings. Those folks were never to convince that the mtl file is part of the obj file specification. And more than one material kills the UV mapping. DXF and 3DS crashes, means they are useless (tested with dxf and 3ds from several apps. Maybe i have missed the one 3ds or dxf version that should work). Even the best working LWO comes in with partially destroyed mapping here and there.

Export: Obj exports not more than one material, and no material settings. See above, it writes no mtl file. But Obj has no bones animation anyways, so why export with it? DXF and 3DS crashes as usual. Both formats have the same issue than Obj anyways, no bones export. FBX exports just one material. With more than one material i get a shot down UV. Even with the patch applied that promised to fix this issue. I cannot remember the issue with LWO, but i remember there was one.

I have simply no working pipeline, no matter which path i choose. And the support didn`t help. I provided examples and descriptions. But they stopped the conversation at the point where i tried to explain what the mtl file is good for, telling me that the mtl file was never part of the specification. And so i never got an answer or a fix for my FBX problem.

Those folks have simply no clue what they are doing when it comes to file formats. At least in Version 5 it didn´t work.

They have no clue about UI and usability neither by the way. When you need a two sided tutorial to explain how to load a simple diffuse, then you should know that you have a UI problem ...

Last edited by Tiles : 04 April 2013 at 09:24 AM.
  04 April 2013
I'm not totally sure why it would be so necessary for you to transfer materials from pM instead of just applying or re-applying them in your final destination for rendering app, it's not like you're going to build UV maps or textures in pM.
  04 April 2013
That`s not the point. When i import or export a mesh with more than one material applied, no matter with what format, then i always end in a shot down UV. Most of my characters have more than one material applied. And this means i have no pipeline. No matter if i am willing to fiddle with reapplying the textures and materials or not.

And that`s not the point because file formats have specifications for good reason. In best case half working and in worst case crashing file formats are worth nothing. And leaving a user alone with a broken pipeline is also no option.
  04 April 2013
I only wished they'd developed a muscle/muscle-rigging system to help animators/new animation TDs trying to move into more realistic/less toony characters. The Muscle Bones are good for some types muscle deformation under the skin, but not all of them. It's been a long time now that muscle has been a part of a lot CG animation some developer should integrate a kind of modular muscle rigging component instead a lot of separate big companies custom coding and doing trial and error individually.
  04 April 2013

There have been several companies that have taken a shot at commercial muscle deformation solutions. Some form of muscle toolkit ships with Maya and Houdini. Can't speak to XSI. ACT (Advanced Character Tools) used to exist for 3dsmax as a plugin that supplied muscle deformation, though it was difficult to set up.

Problem is, muscle systems get complicated fast and don't support real time interactivity as a rule. Weta's tissue system runs totally as an offline sim for example. Those folks animate and then walk away for a day to let the sim bake. A freelancer doesn't have the expertise in general to deal with complicated systems like that. Studios employ whole teams of TDs to make their sims work. The notion that you can package all the expertise up in a box you can buy off the shelf seems unlikely to me.

Messiah's texture deformer on the other hand does a decent job of faking muscle and bone displacement with texture maps. Lightstorm's L3Deformer can do something similar to it. So solutions exist, if you're not tied to anatomic accuracy. After all, you need this deformation for a shot, no? Once you're close enough to what you want for camera, you can move onto the next shot and not worry about how you got there.
"I am a leaf on the wind..." -Wash
  04 April 2013
As to the materials/UVs being messed up...what can I say it's been a constant problem since there have been more than one software developer making 3D software. 3D software developers have been staunchly against application development since the beginning and users have complained about it to varying degrees since the beginning. There's always been problems because the formats aren't "Open" to begin with and I've always thought the companies that make the formats (AutoDesk=OBJ/FBX) change the format specifications without notifying 3rd parties intentionally to create incompatibility just because they want force users under one roof for all their software needs.

Collada was bridging the gap, but I suspect AD is not really going to be very supportive of Collada moving forward, but we'll see. I haven't used it yet, but Alembic seems like a format that could do the same types of things, but it also seems more focused on transferring point caches for meshed simulations more than preserving stuff like UV mapping, materials, textures etc. You're best bet is to either stay under one roof with all of your software, or do materials/textures separately knowing you're going to have to transfer attributes manually or start writing custom scripts to automate this process or look into something like Okino Polytrans or Point Oven and find out if it actually works between your target apps. (haven't used this with pM) or try to treat the pM animation like capture data and just transfer the bone animation or go to the MDD transfer method which just sends the cached vertex animation and that is pretty common now.

Pixologic had to develop GoZ to start to deal with some of this software warfare type stuff. There's an exhaustive list of tutorials littering the internet on UV/material transfer and coding tips for automating this kind of thing which is useful in app, but it's also for bring stuff in from external apps and getting them back up to speed:
  04 April 2013
I'd be interested in this if there was an actual Mac version that worked on more recent versions of OS X, kinda useless otherwise unfortunately.
figdigital | @figdigital
  04 April 2013

I get what you mean, but I guess I keep thinking that all of the visible muscles are in the same positions in all humans and comparatively quadrupeds also are anatomically similar. There are minor to major differences in the proportion of muscle from body to body, but the general shape is pretty similar due to the fact that the muscle tissue, tendons and ligaments function identically. Because of all of these similarities it seems like there could be a basis for assisted automation in this area, maybe something like Face Robot in XSI.
  04 April 2013

I don't know that material export works terribly well out of any application. Material networks from Maya aren't going to translate well via FBX in to Max for example. If you're transferring assets between programs, you'd be foolish to do look dev in one and then expect it to not have to be fixed in the next. That's not how things are done, so far as I understand it. So that Messiah doesn't put out MTLs that are usable doesn't seem terribly important to me. That it mangles OBJs UVs however, that's a bit more concerning.

That said, there are pipelines you can use with Messiah that don't entail bumping into these problems. For example, you could use Messiah for Character Rigging and Animation, bake out your deformations to MDDs, apply the MDDs in your rendering application and do your look dev there. That way you don't replicate your materials setup. You could use Messiah's renderer and simply not come back out of Messiah once you go in. Both are valid pipelines that I know have been used successfully.

Also, don't get me wrong. I'm not defending Messiah. I've got my own issues with the program that I'll not go into here. I'm just saying that folks do use it quite successfully. They've simply adapted their workflow to the limitations and strengths of Messiah. If you're willing to do that, you can adapt it into your pipeline. If not, then you're better off finding software that works the way your expect it to.
"I am a leaf on the wind..." -Wash
  04 April 2013
When that`s not defending Messiah, then i don`t know what is

Why should i be so crazy to stretch my workflow with a dozen workarounds for something that works without a workaround in another app? Besides the fact that there is no workaround for my problem. I have chosen the much simpler workaround instead: I use something else now, something working. I was just curious if they had fixed the flaws.

I am not really unexperienced. I do 3D since several years. So yes, i know what you are talking about. But those import and pray times should be the past. Even more with such super easy file formats like Obj. This is the 21st century, even in 3D. The common file formats are documented enough nowadays. Besides that, i`m a hobby game developer, means code is also nothing foreign for me. And from that angle i simply have to say, no, it does not have to be that way. It`s the opposite, this case is how it should definitely not be. Not anymore. Messiah is a negative example here.

Not working im- and export, a manual from the former version (yes, version 5 came with the manual from version 4) , a UI where you need a big tutorial just to apply a simple texture, a support that quits replying instead of helping with the problem, lots of flaws and bugs, developers that lives in a golden tower (there`s not even a official Messiah forum, the one that exists is managed by the community), nope, that`s very unique in this constellation. I have never ever found a commercial app like Messiah, and i thought i have seen everything before that. Normally you find one or two of those flaws in one app. Not all together.

What really amazes me is that the app still gets bought. Every other app with much fewer problems is long gone because nobody bought it anymore.

Anyways, when it works for you, then best of luck with it. My advice for all others is: keep your hands away

Last edited by Tiles : 04 April 2013 at 07:09 PM.
  04 April 2013
Works great for me too. Since I mainly use it for character animation and rendering, it has great tools (like the graph editor, rigging, Arnold, breakdown slider, sketch, etc). And, I do all my shading and texturing in it too. No need to export anything out, unless, you have a very specific, narrow pipeline. Then, you probably need to use another tool.
It's better to have tried and failed, than to have failed to try.
Thread Closed share thread

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Society of Digital Artists

Powered by vBulletin
Copyright ©2000 - 2006,
Jelsoft Enterprises Ltd.
Minimize Ads
Forum Jump

All times are GMT. The time now is 07:13 AM.

Powered by vBulletin
Copyright ©2000 - 2018, Jelsoft Enterprises Ltd.