Rendering

[hoochoochoochoo]

is the renders out of AM really not in the same league as other apps like LW and C4d?
Thanks-don't apologise for posting or for asking questions! that's what the forum is for, you won't get slapped down here.

One answer is that the render is as good as you want to get from it. If you put the work in then you'll get great results. One area where there is little dispute is when you need larger sized images from AM. I may need to get very large images from a 3D software package soon for display on a stage and AM will struggle to give me the professional quality for a video projector to cope with if I want really high resolution images. And I do want huge renders..
Other apps like C4D and ElectricImage have (backstage) settings that'll handle huge renders as they are built for that anyway. Most renderers will give you a default 72 dpi render and handle monitor / internet resolution fine so if that's what you need - don't fret it.

I've played with XSI and that has an impressive Mental Ray renderer but the cost is out of most peoples pocket. To use that or Maya for web output is way overkill in my book. Mind you, there were some really amazing effects shown by the demonstrator. Truly crazy effects using image maps in post effects but these are truly specialist. Probably no real use just yet to most of us normal users.

[JoeW]

Sorry for another post - :) But is the renders out of AM really not in the same league as other apps like LW and C4d? Maybe its just me coming from Ray Dream :eek: but I think AMs render especailly with photon rendering and motion pass is fanatstic and just as good. But where does it break down when you compare it to the other apps? I know its slow but thats why you buy a bunch of cheap PCs!:thumbsup:
Thanks-
AM's renderer has improved leaps and bounds beyond what it was pre-version 10.5. It's limitations are related to how far you can push it before it "breaks" and the level of control you have vs other renderers. For example, I don't think you could do a 2K render out of AM (I'm talking about film resolution frames) - but how many people need to do that? Also, the control over surfaces - using maps to control things like specular color - gradient maps to blend between effects, better displacement mapping, etc - these are controls that are missing in the renderer.

All renderers have strengths and weaknesses, (AM has a kickin' TOON renderer) and some have more weaknesses than others. I wouldn't say that AM has a "bad" renderer - it just takes a lot of work to make the jump between a "good" render and a "great" render. You often have to "cheat" to make your scene look "right" - moreso than in some other renderers - it's really hard to put your finger on....

Let me also say that there isn't a renderer out there that I don't tend to touch (even just a little) in post - even Mental Ray and Lightwave get tweaked to achieve a specific look. Most of the time, I render out passes (diffuse pass, specular pass, reflection pass, etc) and composite them - this allows a huge amount of control, and the ability to make changes without re-rendering. I wish that AM allowed this kind of rendering more easily (by just checking and unchecking "flags" in the renderer), as opposed to creating new scenes for each pass - but it doesn't, so you have to get it as close as possible in one pass in AM, then maybe create new passes as required (which is a PITA if you have small changes in your scene).

Hash has to juggle between "ease of use" and "professional features" - it's a tough line to walk - but they've found a business model that works for them. Most of their users are hobbyists - and most won't ever push the rederer to it's limits - so ease of use tends to get the nod - (although they do stick a few "pro" features in there from time to time).

It's not the brush - it's the artist :)

JoeW

[hoochoochoochoo]

It's not the brush - it's the artist :)

hey Joe, I "think" you're saying the same thing as I tried to say and I agree the artist thing but sometimes you realise the tool or brush is not what you need to get the job done. I will need film resolution quality if I go CG for an upcoming paid project and it won't benefit me beating the wrong tool to do a job I know it's not designed for.

Apart from that, maybe I should run my answers by you first, you say it so much better! :)

[JoeW]

hey Joe, I "think" you're saying the same thing as I tried to say and I agree the artist thing but sometimes you realise the tool or brush is not what you need to get the job done. I will need film resolution quality if I go CG for an upcoming paid project and it won't benefit me beating the wrong tool to do a job I know it's not designed for.

Apart from that, maybe I should run my answers by you first, you say it so much better! :)
I agree completely - sometimes, you need a hammer, not a screwdriver :)

I also agree that if you're looking for film-res stuff, you should probably put AM aside and find something that can crank out those huge renders. ElectricImage kicks booty at this, C4D does, too. LW is a little more sluggish, but has a really nice render quality...

I think I was typing my response as you were posting - I should have checked before I posted as I, too, think we said just about the same thing :)

JoeW

[Wegg]

I also agree that if you're looking for film-res stuff, you should probably put AM aside and find something that can crank out those huge renders.
Thats the thing Martin Hash and I always butt heads against. It is possible to create interchange methods that allow for the work to be done in the package that does it best for anything other than AM. Martin claims that if you need it you can create it and points to Avalanche. I don't want to have to use Lightwave. . . but I have too due to very demanding render requirements. And its a pitty that I as a very small studio can't use AM WITH lightwave to do the "film-res" stuff like I do with Messiah now.

Ok I'm ranting. . .

Should I hit the Submit Reply button. . . ? Did I really add anything to the conversation or did I just open up another can of worms. . . why am I typing this. . .

[pequod]

I wish that AM allowed this kind of rendering more easily (by just checking and unchecking "flags" in the renderer),

Hash will hopefully introduce split renders with v11.5, using the OpenEXR format (whatever that is). It was the number one feature the 'Hash Fellows' voted for and that Martin is busy programming.

[John Keates]

Pequod - "Hash will hopefully introduce split renders with v11.5, using the OpenEXR format (whatever that is). "

Cool, I knew that split renders was planned but I didn't know that the OpenEXR format was going to be used.

One thing I would like cleared up if anyone here is in the know: aparently the AM renderer uses 32-bits, so is that 32 integer bits or 32 floating-point bits? If it is only integers then wouldn't this be a good time to upgrade the code and delve into the world of HDRI? (I am assuming that 32 integer bits is not enough for HDRI). If it is 32 floating-point bits then doesn't that mean that HDRI would be easy to implement now?

At this point, John starts to feel out of his depth, just hoping that some pearls of wisdom that he can understand will come his way to satisfy his geeky lay-mans desire to learn about rendering and stuff.

[Drakkheim]

openExr is a file format, developed by ILM, which allows for an arbitrary number of channels. (among many other things,like 16bit colordepth )

A nice overview of it can be found here http://www.gimlay.org/~andoh/cg/lib/openexr/details.html


It's A good thing :)

[ypoissant]

One thing I would like cleared up if anyone here is in the know: aparently the AM renderer uses 32-bits, so is that 32 integer bits or 32 floating-point bits? If it is only integers then wouldn't this be a good time to upgrade the code and delve into the world of HDRI? (I am assuming that 32 integer bits is not enough for HDRI). If it is 32 floating-point bits then doesn't that mean that HDRI would be easy to implement now?
A:M uses 32 bits floating point in its calculations. Color is computed and internally stored as 3x32bit floats. Internally, A:M computes in almost unlimited dynamic range internally just like almost all 3D apps out there.

HDRI refers mainly to an image file format which can represent more than 256 levels. It have little to do and is independent with how the color data is computed inside the application.

Rendering with HDRI involves much more than the data format. In particular, unless you want to render highly specular objects with HDRI, you need a quite sophisticated optimization of sampling and filtering mecanism on the HDRI illumination image. And since most users want to use HDRI images to render diffuse or semi-diffuse surfaces Hash would have to implement such a filtering mechanism. It is because of this filtering mechanism that rendering with HDRI eats so much processing power. Any naive implementation will eat so much CPU that it won't be practically usable. And implementing an optimal sampling/filtering algorithm will require a solid investment in development resource. Whatever the case, HDRI will use much more processing power than simple lights. To give you an idea, depending on the specularity of the surfaces to render, you can figure an HDRI lit scene to be roughly equivalent to a scene lit by a 50 to 500 lights skydome.

If I were Hash, I wouldn't put HDRI very high on the priority list because of the higher render times. Most users already complain because multipass takes time and nobody uses photon mapping because it takes too long. Even skylights are not much used because of the longer render time. So why would Hash invest time on a feature which nobody will use in the end?

Yves Poissant

[hoochoochoochoo]

I agree completely - sometimes, you need a hammer, not a screwdriver :)

---------------snip------------------
ElectricImage kicks booty at this, C4D does, too. LW is a little more sluggish, but has a really nice render quality...

I think I was typing my response as you were posting - I should have checked before I posted as I, too, think we said just about the same thing :)

JoeW
You are a gentleman sir and I appreciate your response.

Should I hit the Submit Reply button. . . ? Did I really add anything to the conversation or did I just open up another can of worms. . . why am I typing this. . .
hehe! I think "Violet whatshernumber" has resurrected herself in you Wegg..

Hash will hopefully introduce split renders with v11.5
----------------snip-------------------
the number one feature the 'Hash Fellows' voted for and that Martin is busy programming. Hey! any chance the Hash Fellows could update us on this type of news more often?

I wouldn't put HDRI very high on the priority list because of the higher render times. Most users already complain because multipass takes time and nobody uses photon mapping because it takes too long. Even skylights are not much used because of the longer render time. So why would Hash invest time on a feature which nobody will use in the end? I thought when we last had a general Poll or discussion most of us agreed Render Quality was more important than speed? There is a side point to this that faster processors could mean faster better renders but all programmers everywhere keep finding extra bits to add to an application thus slowing down the improvements. I am a fan of multipass - it's flexible and allows you to choose how many passes you require - much like C4D gave you with it's anit-aliasing feature.
As to Skylights, Yves I hope you are wrong. I still use some of the set-ups you gave away long ago and I'd hate to see them discarded. Maybe the newer users don't even know about these features or haven't seen any examples?

[Wycoff3d]

Split renders sounds great! But what does Hash need to do to let AM do 2K renders? Is it a limitation of AM or is it just needing a rally killer PC with leaps of ram!? So I wasnt to far off saying AM renders are just as good as the other apps!:thumbsup:

[ypoissant]

As to Skylights, Yves I hope you are wrong. I still use some of the set-ups you gave away long ago and I'd hate to see them discarded.
Strange jump to strange conclusion.

I never wrote that already implemented features would be removed or discarded. Beside, Skylights are not features but only standards models, lights and actions files organized in some clever ways. How could they be discarded?

Let me rephrase what I wrote:
Indeed some users would like HDRI implemented in A:M. I am one of those users BTW and I actually worked on some HDRI code for A:M a few month ago. After the first naive prototype implementation, the render time jumped by a factor of up to 500 times on non specular, pure diffuse surfaces. Render time multiplicative factor decresese as the surface becomes more and more specular. Render time increases in about the same proportion as for soft reflections in relation to surface specularity but is actually proportionally larger. Then I started reading all the available published papers on optimizing HDRI. There are indeed several tricks available for optinmizing HDRI render time. The most efficient tricks are also the hardest ones to code. We get nothing for free here.

So the situation with HDRI is this:
Quickly concocting and HDRI render node in the renderer pipeline will result in an unacceptably slow HDRI implementation which nobody will use. In order to implement a usable HDRI, the investment in development time will have to be quite high.

I, for one, stopped working on HDRI because I didn't have the feeling that it would be used in the end. I had the feeling that it would not be used any more than photon mapping (which BTW, is very related to HDRI). When was the last time we saw someone using photon mapping? There was a time, before the implementation of photon mapping where some very vocal users insistently requested GI and Radiosity in A:M. Where are they now that this is implemented? I think I saw a couple examples of its use but that was it. This is why I wrote "If I were Hash". So I am not talking in Hash name here but only in my name and I don't know Hash own plans for HDRI or for any future features. But if I were Hash, for all those reasons, HDRI wouldn't be placed very high on my priority list.

[modernhorse]

from Wegg - And its a pitty that I as a very small studio can't use AM WITH lightwave to do the "film-res" stuff like I do with Messiah now.So I gather from what I read here, that there is really no clear way to output animations from A:M into another package? I know folks do it, but I mean little guys like me - there isn't any way ? Am I just wishing for something that will never be? Am I adding nothing to the conversation? :)

And Oh yes I'll agree with JoeW, A:M does have a kickin toon renderer. I love it!

[John Keates]

I see what you are saying Yves. I guess I was being naive thinking that high bittage means HDRI. I think you are right about people not using it too. It is nice for making stills look pretty but not so good for animations.

[hoochoochoochoo]

Strange jump to strange conclusion.

I never wrote that already implemented features would be removed or discarded. Beside, Skylights are not features but only standards models, lights and actions files organized in some clever ways. How could they be discarded?

Forgive me for poor wording Yves. I re-read my post and it indeed does suggest skylights are a feature within the application. Sorry for any misinformation to anyone reading my words. No, I was just reacting to your saying that few people use skylight set-ups- I in my turn was saying that maybe newer users have not come across the idea of Skylights so maybe it was a case of showing some good stills and tutorials. I know tutes exist but if people aren't using skylight setups then maybe the tutorials aren't working?

I'll shut-up now.

[hoochoochoochoo]

So I gather from what I read here, that there is really no clear way to output animations from A:M into another package? I know folks do it, but I mean little guys like me - there isn't any way ? Am I just wishing for something that will never be?hi Horse-Dude person, what you're talking about takes specialist coding or clever work using the bvh or whatever mo-cap format that hash can IMPORT / EXPORT. It is a lot of effort whichever way. The alternative is for AM to communicate better with other apps but as we've read often before on this forum that is a route Hash will not and doesn't want to go down.

Tell you what though - YOU set up a thread where you are going to try this from the little guys perspective and post progress. People may chip in with help and examples and then that would become a resource in itself. I'm not being silly here, this forum does have a lot of knowledgeable users. It may take time but it can work. I've learnt lots by setting up WIPs myself and getting feedback.

YOU'LL NEVER KNOW UNTIL YOU TRY....

[modernhorse]

YOU set up a thread where you are going to try this from the little guys perspective and post progress.

Thanks for the reply Hooch. Hmm ... now you've got me thinking. But I'm such a little guy.

[hoochoochoochoo]

But I'm such a little guy.
I'm struggling to resist the humorous replies..

.........!

OK, being serious - start with a premade mesh (this thread wouldn't be about modeling) and then see what suggestions you get about the most appropriate rig etc etc. C'mon Horse-Dude, think about all the contests YOU got me into....

:scream:

[modernhorse]

I'm struggling to resist the humorous replies shut up ya bastage !

C'mon Horse-Dude, think about all the contests YOU got me into....
shut up ya bastage !

Bastage - a term used in "Johnny Dangerously" a movie that I've never sucessfully watched from start to finish. One of these days.

Okay, well let me think more about this. Let me explore the limits of my brainpower and see if I can get my head around some of the basics required here. After all, I'm such a little guy.:D

[Wegg]

So I gather from what I read here, that there is really no clear way to output animations from A:M into another package? I know folks do it, but I mean little guys like me - there isn't any way ? Am I just wishing for something that will never be? Am I adding nothing to the conversation? :)

Everything is there for you to do it. BVH Export, Geometry export, documented api etc. Its just a lot of work and you will hit some walls that make it very un-efective for any real production.

You should probably reach the limits of AM itself before worrying too much about it though. Net-render for AM is the best network render manager I have ever used. When your using that with a large farm and it still isn't doing it for ya. . . THEN worry about it. :)

[JoeW]

.......... Any naive implementation will eat so much CPU that it won't be practically usable. And implementing an optimal sampling/filtering algorithm will require a solid investment in development resource. Whatever the case, HDRI will use much more processing power than simple lights. To give you an idea, depending on the specularity of the surfaces to render, you can figure an HDRI lit scene to be roughly equivalent to a scene lit by a 50 to 500 lights skydome.

If I were Hash, I wouldn't put HDRI very high on the priority list because of the higher render times. Most users already complain because multipass takes time and nobody uses photon mapping because it takes too long. Even skylights are not much used because of the longer render time. So why would Hash invest time on a feature which nobody will use in the end?

Yves Poissant
I agree that a true HDRI lighting feature would probably be a lot of time invested in something that doesn't get used (or ends up very, very slow) - but what would be a very nice feature (or plugin - hint, hint) would be something that would generate a light rig from an HDRI image (or any image, for that matter). XSI has this, and it's very slick - it lets you choose how many lights you want to use in the scene, it picks the strongest to the weakest appearant sources in the image and then creates lights (including colors of light) based on those "sources". You can then use a panoramic image as a reflection map, and you're right up there next to HDRI lighting without the complexity (AND with the ability to "tune" the lights).... nice.

JoeW

[JoeW]

Hash will hopefully introduce split renders with v11.5, using the OpenEXR format (whatever that is). It was the number one feature the 'Hash Fellows' voted for and that Martin is busy programming.
Stephen,

When you say "split renders" are you referring to separate passes, or to what is also called "bucket rendering" to improve memory use? (actually, both would be nice...)

JoeW

[ypoissant]

When you say "split renders" are you referring to separate passes, or to what is also called "bucket rendering" to improve memory use?
Split render as in seperate passes. OpenEXR allows that.

[Obnomauk]

I'm still unsure about OpenEXR... all I really wanted was folders of targa files :/ now I have to learn how to use a format I had never heard of to composite.

for those of you who are more in the know on this than I... how would a typical implementation of this format be handled? how would I take say an OpenEXR sequence into AE and adjust the hue of a particular light? can I take individual aspects out of the OpenEXR image for alteration and layering? I've read the web page and frankly that's only enough information to make me wonder if what I need is possible with the tools I have at hand. I'm going to use it if it kills me cause frankly the time I spend setting up render layers now is pretty high, so anything should be an improvement. and if it's not well it is documented that they only way to get hash to improve things are to use them :)

seriously though if anyone has any information on how this is used in a practical sense in compositing (I have AE) then I would be grateful.

either way as soon as it is available and I have it figured out there will be a litany of tuts on it...

... after this bucket rendering is my next render request :)

-David Rogers

[Wegg]

I have to agree with Ob. OpenEXR seems sci-fi where as folders of Targa stacks or even PSD stacks make a lot more sense.

In LW you can render all the spec, color, depth etc into layers of a PSD file. 16 bit floating point or just 8 bit. . . thats up to you. After Effects and Photoshop read em in just fine. So does Digital Fusion.

Ob. . . I think it will be like Lightwave's RLA format where you can isolate different parts of the image. It isn't nearly as intuative as if it were a PSD file with everything in seperate layers but. . . it seems to work.

http://www.dougplanet.com/tut-rla-fun.html

Have a look there.

[ypoissant]

There is a Photoshop plugin for opening and saving EXR files. Each layer in an OpenEXR file can contain much more information than a Photoshop layer. You can start here for the plugin:

http://www.openexr.com/photoshop_plugin.html
and then
http://www.openexr.com/downloads.html

Once in Photoshop, you can save it in psd format.

A plugin for AE is also expected in a future OpenEXR release.

[Obnomauk]

Yves, do you have any links to EXR images that have something more than just RBGA channels in them? I presume that the images in photoshop would split layers out via channels... (but I could be wrong as no one anywhere has any information that I can find on this) which is kind of a pain when you want to change say a blend mode... you can of course copy the data out of a channel and paste it to a new layer, but targa stacks would have been more intuitive... and in AE i'm not 100% sure how that would work... again if there is a resource where I could see some sample images that would be a HUGE help.

-David

[Wycoff3d]

Me HDRI isnt to high on the list. Im still learning photon mapping which as amazing! Thanks Yves!:thumbsup: But Im trying to see how Hash can work around the 2K limit. A friend (more of a acquantince) of mine uses C4d for rendering huge poster size images. I wish that AM could do this so maybe I can get some work from him!:D

[PJC]

For my comic work I usually end up rendering 3k X 2k and AM is slow, but it will render. AM just uses A TON of memory when it renders big. Eggslice was a great way around that (we actually used a similar feature in Maya in the command line to split up our renders for large format animation projects and then re-assembled them in post).

I just bought more RAM.

Also, we were doing a LARGE project in C4D and although it takes LESS RAM than AM to render, I still needed 3GB of RAM for the DODGE project. It was huge tho.

- pjc

[modernhorse]

Everything is there for you to do it. BVH Export, Geometry export, documented api etc. Its just a lot of work and you will hit some walls that make it very un-efective for any real production.

You should probably reach the limits of AM itself before worrying too much about it though. Net-render for AM is the best network render manager I have ever used. When your using that with a large farm and it still isn't doing it for ya. . . THEN worry about it. :)
Thanks Wegg. I sort of gathered this by doing some experimentation over the weekend. I can see that it can be done, I just think it will add alot of crap to my plate at the moment. I have enough crap on my plate. Thanks for the input.

[CGTalk Moderation]

This thread has been automatically closed as it remained inactive for 12 months. If you wish to continue the discussion, please create a new thread in the appropriate forum.