External Renderer?

[ypoissant]

That's what I've always been wondering... I didn't see how it was possible to use an external renderer without redoing all the lights and textures in that other environment.

 

So... it's not possible. You need to learn all the materials and lights of that other renderer to get the result that that renderer gets.

Exactly.

 

Especially regarding materials. Material properties in A:M are visual properties: a palette of adjustable visual effects. By adding and adjusting those visual effects, the artist gets a given for look.

 

A physically based renderer needs physical description of how light interacts with materials. It is impossible to convert a combination of visual effect into physical description of materials. At worst, the combined visual effects would result in physical impossibilities or result in contradictory physical properties. At best, the conversion would result into a material that remotely looks like the combined visual effects.

 

Same for lights but it is easier to infer physical properties of lights from their combined set of visual effects.

 

Note that I make a distinction between textures and material. A material includes a set of textures but could also be defined without textures. This said, textures used to drive some visual effects would be particularly troublesome in some cases because their values could not be used to drive physical properties.

[robcat2075]

A physically based renderer needs physical description of how light interacts with materials. It is impossible to convert a combination of visual effect into physical description of materials. At worst, the combined visual effects would result in physical impossibilities or result in contradictory physical properties. At best, the conversion would result into a material that remotely looks like the combined visual effects.

 

So, thinking this through a bit further... to use that other renderer you either need to use the stock materials it provides OR know a lot about real physical substances so that you can create new materials to accurately represent the substances not already covered by the stock materials.

 

I think knowing a lot about real substances will be more technical than most 3D artists are up to. If creating new A:M materials is too hard for most people then creating new physically based materials will be too hard.

 

I f the external renderer has an enormous library of ready-to-go materials that covers all the likely possibilities then that might not be a problem.

[John Bigboote]

I f the external renderer has an enormous library of ready-to-go materials that covers all the likely possibilities then that might not be a problem.

 

I've been toying with getting my mesh's out of A:M(via .obj and .mdd) and into C4D and (as you mention) re-assigning C4D's deep library of shaders/materials one by one... it IS possible and it IS a pain in the butt- especially re-assigning decals that were a snap to apply in A:M into C4D's UV editor. A:M's channel editor is far simpler and FAR superior to C4D's... there are things back and forth that are better in one than the other, but A:M sure holds it's own!

 

I was talking to Mr. Bones (Joe McPeek) today and he is expanding his motion-capture library into the world of animals, wow! He mentioned that if A:M could use FBX files it would open-up WORLDS of possibilities.

[ypoissant]

So, thinking this through a bit further... to use that other renderer you either need to use the stock materials it provides OR know a lot about real physical substances so that you can create new materials to accurately represent the substances not already covered by the stock materials.

 

I think knowing a lot about real substances will be more technical than most 3D artists are up to. If creating new A:M materials is too hard for most people then creating new physically based materials will be too hard.

 

I f the external renderer has an enormous library of ready-to-go materials that covers all the likely possibilities then that might not be a problem.

That is what I think too and why I was interested in knowing what people expect from using an external renderer.

 

Physically based renderer do come with a rather large base of materials. Some of them are measured materials. But they are real-world materials and even though there are many, they may not suit some particular project. In this case, the artist need to define its own material. The material editor strictly enforces physical plausibility though. But still, one need to know a lot about materials, their composition and how they react to light in order to compose realistic materials. Of course, experimentation is always possible.

 

So I share the impression that dealing with physically defined materials is probably more technical than most 3D artist are up to. It is whole different culture. The experience gained in defining visual effect based materials will not be transferable to physically based material.

 

This said, Disney have designed a physically based material definition interface for artists that uses the same idea of adding and adjusting visual effects except that those visual effects have a meaningfull physical relationship. Some of those visual effects have similarities with the ones used in A:M but most are new. Maybe in a few years, this will be commonplace and physically based renderer will be more accessible.

[robcat2075]

it IS a pain in the butt- especially re-assigning decals that were a snap to apply in A:M into C4D's UV editor.

 

Why do you have to reapply decals? I've exported an OBJ and it had decals survive for the polygon app.

 

Is "re-assigning" something else?

[detbear]

I have appreciated the ease of setting an A:M model up for applying textures in other Apps like Vue and Lumion.

 

When I export the models out of A:M to say....Vue....I have areas named and colored. They often look like colored circus tents.

 

After importing them into Vue, these grouped regions become the targets for applying the materials in other Apps. I'm certainly no expert in

building materials in any package. But it isn't all that difficult to get the basics of building the surface materials in a different package.

 

The motivation being the end result you desire to acheive.

 

Admittedly, in most architectural projects I do with Animation Master, A:M is only used as a modeller. The rest is done in the other App.

[Rodney]

When I export the models out of A:M to say....Vue....I have areas named and colored. They often look like colored circus tents. smile.gif

 

Here's the part where I think I get lost.

Are you saying that your Named Groups and (basic) Surface properties are retained in the exported model?

I've always had trouble 'creating' groups in .obj files (they might be there in the model but the external program doesn't suggest they are there) so that would be a very handy thing to learn.

[Xtaz]

Are you saying that your Named Groups and (basic) Surface properties are retained in the exported model?

When I export a model to OBJ, I have Named Groups with its basic color. Using Octane render I just have to drag a material in each group.

[Rodney]

When I export a model to OBJ, I have Named Groups with its basic color. Using Octane render I just have to drag a material in each group.

 

Thanks, obviously I haven't tried very hard.

It's good to know that the Named Groups and colors get through intact.

That alone is very useful.

 

My naive view on the subject has me thinking folks have made this much more difficult than it needs to be in that any instance where those groups are preserved it is (relatively) trivial to assign materials to the existing group (and much of that can be automated). If the group is identifiable (i.e. by it's group name created in A:M) then (as Robert suggests) it becomes mostly a matter of swapping textures/materials out.

For instance if three folders are created:

 

Live

A:M

Other

 

Where the files in the live folder are written over as required and the files in the other folders are (for our purposes here) static.

The program always points to the same location (regardless of program) while the targeted data from service/provider is then borrowed just in time.

 

One obstacle to this is the naming convention we normally use with files (we see a file extension and begin to assume things (correctly or incorrectly) based on the assigned type).

But ultimately we (the end users) don't care about the file type, we simply expect it to work every time.

Any file named the same as the Group in the Live folder will work in the scene with texture and lighting. (Here we implement a system that can measure the degree success via the users reaction)

So for the users purpose all the files in the Live folder are extension-less (they simply serve as a bridge between otherwise incompatible files).

 

Of course, behind the scenes the program must know the file type in order to deal with it correctly.

Any program could look at the live file and determine if a texture or material named 'Tire' is present.

If present it proceeds with the test to determine if the correct tire-type can be applied.

If the correct tire-type is not present the program prompts the user to supply it.

Once supplied the object is tired/re-tired.

 

This becomes even more trivial when the data in the Live folder isn't physically based but stored in memory (where algorithms can fully optimize them).

 

So in the end the problem is not overly complicated but boolean in nature.

Then (with regard to user experience) one need only test for false positives which is information the user supplies.

 

At the beginning of the collection of files there are many incompatibilities but the more the system is used the more it reduces to fewer and more trivial incompatibilities.

Perhaps the most important thing however is that once in its proper place it can then be relied upon.

 

Added: I should make this post of some use so here's a link to the Mitsuba renderer: http://www.mitsuba-renderer.org/devblog/

(I checked out online renderer Yves posted a link to. Very nice.)

[Xtaz]

How about A:M to export .ORBX file???? Is this a dream ???

 

 

".ORBX, the most powerful 3D interchange file format available today – The new .ORBX file

format improves considerably on traditional 3D formats such as .OBJ, .CAD, or .STL, going beyond

storing simple geometry to include all aspects of a 3D scene, such as materials, properties,

textures, lighting, transform hierarchies and cameras, all in a self-contained file format. Unlike the

Alembic file format, .ORBX was designed in close collaboration with Autodesk and Mozilla to be a

flexible container for a wide range of uses beyond computer graphics, including video, 3D printing,

holography, design and engineering. The .ORBX format allows for incredible granularity, supporting

the modeling of physical properties of a scene or object down to two hundredths of a nanometer,

or a quarter of the size of a hydrogen atom. OctaneRenderâ„¢ 1.5 and related plugins allow artists

and animators to perfectly import and export extraordinarily complex 3D scenes in .ORBX format

across 15 modeling programs, appearing in the same final render quality as the program they

were originally created in. The flexibility of the .ORBX format has implications for media and

entertainment companies who can now effectively use their computer-generated assets and IP

across a variety of mediums, from feature film and television development, to video games, web

sites, and toy production for example. The format is expected to be open sourced in the second

half of this year."

[Elm]

How about A:M to export .ORBX file???? Is this a dream ???

 

.....

 

The format is expected to be open sourced in the second

half of this year."

 

 

Wow. THAT sounds interesting!!!