thanks 1/2, that was my suspicion, its just docs lagging
functionality a little.
I'll apply a little common sence in the mean time.
_sam
Halfdan Ingvarsson wrote:
Use an environment shader rather than a
dome. When using limits on FG rays, the FG ray will fade into the
environment map between the start/end distance. You should always be
working with FG ray limits to minimise flicker introduced by far-away
objects that don't contribute much to the overall sampling except for
artifacts.
I'll be working with documentation to
clear up some of this stuff in future releases and also try to add some
more reasonable defaults.
For the time being: Use "automatic" mode
by default, view dependent, unless you need the FG point distance limit
available in "multiframe". The two legacy modes should only be used if
you're very comfortable with them and/or masochistic.
- ½
I
am running into many contradictions in this thread between user
experience and the manual.
i would really like to get these straightend out.
firstly the prefered mode for a conventional scene, this
is all hypothetical so bare with me: say a modest city
scene (2000 xsi units for a couple of blocks) with a
crowd say ten figures moving around and
camera moving round. And the whole thing is surrounded in a
environmental sphere (this limits how much we can clip the distance of
the fg rays) assume we are rendering a beauty pass, ie
everything at once. basic optimizations, like blurred enviroment
maps are done, but no raytype optimizations
on a per material basis.
my current understanding from suggestions on the list would be to use
automatic and view dependant and overwrite existing file C:\temp\fgmap.
this contradicts the manual: "Automatic
mode primarily targets rendering of single still images"
and i dont see how view dependant
affects this mode as there are no min max settings to define in screen
space?
I can understand the need for a little trial and error, but i like to
base my experimentation on rational trial more so than
exhaustive permiatations of error.
I realise this whole debate is like negotiating the
length of a piece of string, but i just need to know if my approach is fundimentally
correct or flawed?
_sam
Halfdan Ingvarsson wrote:
FYI the [Frame] / [Field] token bug was
reported last week and has already been fixed.
- ½
Hi Tim.
It's maybe me but I still don't get you. You are assuming that FG is
physicaly correct. But in the MR documentation they cleary say that if
you want Physical correctness you need the usage of GI. ( You also need
shader and a tonemapper to achieve this ).
I also agree with Kim. FG is maybe the most misunderstood tools
available in MR. Because of that people thing that FG is unreliable and
produce flicker all the time.
Actually it s the case also of Vray, FinalRender, Brazil and even Rman
(with his new point based AO and color bleending ) and surprisely ( or
not suprisely the same type of flicker ).
But once you have understood of it works you can eliminate easyly
flicker. I can accept the fact it's maybe harder to setup in MR ( from
my POV it 's easy but that's not the point )
I was about to produce ( actually I did ) a scene similar to the brick
test and the ring. Halfgan did it before using direct kind of setup. I
would be delighted to share my scene so you have a look.
To Halfgan :
To come back to the subject. I think there is a problem in the writting
of Fgmap.
If I use render region, my map is written on my disk according to the
token :[Pass].[Frame].fgmap
no problem at all.
But If I use Standard render or preview render, the map is generated
but not saved. Even if you use generate FG map only option.
I also tried by forcing to generate the map by using 'Generate If
doesn't exist'. It generate it and save it for the first frame but the
next frames are ignored. Actually even the generation is ignored. And I
am still using the same token.
I got another idea by forcing the Path of the Fgmap by using a script
that change the FGmap name and path every frame. But the pre render
script or post render script field are not available.
I will post it as bug as soon as I am back from holiday
Harry Bardak
TD / Compositor.
Http://perso.wanadoo.fr/harry.bardak/
+33 6 76 63 35 54
+44 781 661 4147
> From: BauerOink(at)gmx.de
> To: XSI(at)Softimage.COM
> Subject: Re: FG Map Sequences
> Date: Mon, 9 Apr 2007 10:54:57 +0200
>
> O.k.,
>
> since Kim opened that other can of worms containing
> a guess about Joe User often not fully delving into
> the documentation and tutorials to make full use of
> the product at hand...
>
> Based on Halfdan´s example, one should now try to
> artdirect the result a bit, e.g. finetune the effect.
>
> *Extend the lit area (coming from the yellow ring)
> by factor four without having the hot area blow out.
>
> You´ll likely try to simply scale the entire scene to
> extend the area mR uses internally to optimize
> FG point distribution but will still end up with
> blown out hotspots near the source. After some
> fiddling and maybe even some FG map tonemapping
> you´ll get close but won´t be able to say for sure if
> the illumination radius has been exactly scaled by four.
>
> That´s what I meant.
>
> Cheers
>
> tim
>
> P.S: Again, I don´t want to say FinalRender is any better,
> but try hard to point out a - imho - conceptual implementation
> flaw that counteracts reliable usage in many tools available today.
>
> A bit like the difference you find in making a picture with a
> pocketcamera and having it developed in an hour lab and
> using an SLR with a known film and developing it yourself.
>
>
> Since there is a
> ----- Original Message -----
> From: "kim aldis" <kim.aldis(at)gmail.com>
> To: <XSI(at)Softimage.COM>
> Sent: Monday, April 09, 2007 8:50 AM
> Subject: RE: FG Map Sequences
>
>
> > It's worth pointing out also that the anti-aliasing in
Halfy's movie is a
> > deal better than Stage2_Maya_FlickerFree.mov.
> >
> > It's also worth pointing out that often it's often operator
error caused
> > by
> > a lack of understanding of the tools at hand that lies at the
root of the
> > problem. There's a huge tendency to blame the software before
looking at
> > oneself. More tutorials would help. So would a bit more
interest in the
> > documentation. Not always, but often enough for it to be a
concern and
> > it's
> > a shame that it reflects on the product.
> >
> >> -----Original Message-----
> >> From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM]
On
> >> Behalf Of Halfdan Ingvarsson
> >> Sent: 07 April 2007 20:52
> >> To: XSI(at)Softimage.COM
> >> Subject: RE: FG Map Sequences
> >>
> >> Whipped this up in a few minutes using RBDs. I left out
the ambient
> >> blue so you may have to crank up the brightness a little.
> >>
> >> http://www.halfy.net/mental_fg_ring.mov
> >>
> >> Automatic mode, 1500 rays, 40 fg points, 2 diffuse
bounces, max falloff
> >> 40: 50 seconds a frame (average).
> >>
> >> So maybe it's just marketing bluster after all. The Cebas
guys really
> >> *do* like to talk about themselves as if they're the
second coming :)
> >>
> >> - ½
> >>
> >>
> >> -----Original Message-----
> >> From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM]
On
> >> Behalf Of Tim Leydecker
> >> Sent: 06-Apr-2007 05:43
> >> To: XSI(at)Softimage.COM
> >> Subject: Re: FG Map Sequences
> >>
> >> Hi Halfdan,
> >>
> >> here´s a list of links to clips done by various people,
mostly for
> >> demonstration purposes, I´ll try to pick based on FG/GI:
> >>
> >> http://www.cebasusa.com/Stage2_Maya_FlickerFree.mov
> >> (FinalRender, ~1.20min per frame incl. prepass)
> >> http://www.afterworks.com/FumeFX/anims/corridor.avi
> >> (FumeFX, rendered with FinalRender)
> >> http://www.magicpics.com/aquarius/mov/aquarius_mov29.html
> >> (Aquarius, rendered with FinalRender)
> >>
> >> There´s another clip showing RBD bricks and a ball do
their thing with
> >> all GI bells and whistles but I can´t find the link (to
that plug-in?)
> >> nor remember wether that was also rendered with
FinalRender anyway...
> >>
> >> It may be argueable if the above proves FinalRender does
have a
> >> competitive advantage compared to the current mR FG/GI
implementation
> >> or if these links are just my way of proving the bias I
have against
> >> the whole FG/GI concept in mR anyway.
> >>
> >> Imho, (mR´s) FG/GI is unuseable because it´s biased
towards a fast
> >> performance on the cost of truely reliable indirect
illumination and a
> >> physically correct lighting model. Adding physically
correct lights and
> >> shaders doesn´t help if your FG calculations screw it up.
> >>
> >> I know I may get flamed for being to bold but we had this
discussion
> >> before and it turned out that the entire FG/GI thing
isn´t physically
> >> correct at all (thanks to Daniel Rind for explaining the
concepts) but
> >> - again imho - most people using mR are lead to believe
it is
> >> "correct".
> >>
> >> Cheers
> >>
> >> tim
> >>
> >>
> >> ----- Original Message -----
> >> From: "Halfdan Ingvarsson" <hingvars(at)Softimage.COM>
> >> To: <XSI(at)Softimage.COM>
> >> Sent: Wednesday, April 04, 2007 3:01 PM
> >> Subject: RE: FG Map Sequences
> >>
> >>
> >> > Now I'm curious. Have you had any experience using
any of them with
> >> > animation? Is there any truth to this claim, or is
it just marketing?
> >> Is
> >> > it down to better defaults? What are the render
times like?
> >> >
> >> > I'm genuinely interested to know because I would
like to be able to
> >> throw
> >> > something concrete back at mental images
(metaphorically, of course
> >> :-)
> >> >
> >> > - ½
> >> >
> >> > -----Original Message-----
> >> > From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM]
On
> >> Behalf
> >> > Of Marc-Andre Carbonneau
> >> > Sent: 04-Apr-2007 08:29
> >> > To: XSI(at)Softimage.COM
> >> > Subject: RE: FG Map Sequences
> >> >
> >> > What is VRay, Final Render and Brazil doing so that
their FG is not
> >> > flickering like crazy when animated characters or
object populate a
> >> scene
> >> > then?
> >> >
> >> >
> >> > -----Original Message-----
> >> > From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM]
On
> >> Behalf
> >> > Of Alan Jones
> >> > Sent: April 4, 2007 5:56 AM
> >> > To: XSI(at)Softimage.COM
> >> > Subject: Re: FG Map Sequences
> >> >
> >> > That sounds to me like the multiframe mode is a
complete crock then.
> >> >>From the way it's promoted "to remove flicker on
animation" I
> >> expected to
> >> >>support ummm.. animation perhaps? Not jut a
camera flythrough - you
> >> could
> >> >>already fix that yourself by prebaking an FG map.
> >> >
> >> > Good to see Mental Images has a handle on what's
holding back their
> >> FG
> >> > from being useful in production....
> >> >
> >> > Cheers,
> >> >
> >> > Alan.
> >> >
> >> > On 4/3/07, Halfdan Ingvarsson <hingvars(at)softimage.com>
wrote:
> >> >> The logical/efficient thing would've been for me
to set the default
> >> >> mode to "Automatic" to avoid snarky comments ;-)
> >> >>
> >> >> I set the default FG file to have the [Frame]
token because
> >> appending FG
> >> >> points to a single file for a scene with
animation can cause all
> >> kinds of
> >> >> odd artifacts popping up. Point appending, and
hence the
> >> "multiframe"
> >> >> mode, is really only intended if you're doing
static scene
> >> flythroughs
> >> >> and such. Animation may not work as expected and
accumulate a
> >> complete
> >> >> overkill of points.
> >> >>
> >> >> To be honest though, there isn't much
*technical* difference between
> >> >> those two modes. You gain an extra slider to
control a maximum
> >> search
> >> >> radius for final gather points in "multiframe".
That's all.
> >> >>
> >> >> - ½
> >> >>
> >> >> -----Original Message-----
> >> >> From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM]
On
> >> >> Behalf Of Sam Cuttriss
> >> >> Sent: 03-Apr-2007 14:25
> >> >> To: XSI(at)Softimage.COM
> >> >> Subject: Re: FG Map Sequences
> >> >>
> >> >> so when rendering with the new multi frame fg
setting.
> >> >> removing the [frame] token and turning on append
is logical/
> >> efficient?
> >> >>
> >> >> _sam
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >>
> >> >> Halfdan Ingvarsson wrote:
> >> >> > I'm also assuming you've removed the
[Frame] token.
> >> >> >
> >> >> > I just tried this here and it is appending
to the file but only
> >> with
> >> >> > new points, of course.
> >> >> >
> >> >> > If you have a scene that demonstrates
otherwise, I'd love to have
> >> it
> >> >> > :)
> >> >> >
> >> >> > - ½
> >> >> >
> >> >> > -----Original Message-----
> >> >> > From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM]
On
> >> >> > Behalf Of Andre DeAngelis
> >> >> > Sent: 03-Apr-2007 13:56
> >> >> > To: XSI(at)Softimage.COM
> >> >> > Subject: RE: FG Map Sequences
> >> >> >
> >> >> > Hi Halfy,
> >> >> >
> >> >> > Same deal with both Append and Overwrite
existing file.
> >> >> >
> >> >> > Andre
> >> >> >
> >> >> > -----Original Message-----
> >> >> > From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM]
On
> >> >> > Behalf Of Halfdan Ingvarsson
> >> >> > Sent: April 3, 2007 1:36 PM
> >> >> > To: XSI(at)Softimage.COM
> >> >> > Subject: RE: FG Map Sequences
> >> >> >
> >> >> > Have you set it to "Append new FG point to
file"?
> >> >> >
> >> >> > - ½
> >> >> >
> >> >> > -----Original Message-----
> >> >> > From: owner-xsi(at)Softimage.COM [mailto:owner-xsi(at)Softimage.COM]
On
> >> >> > Behalf Of Andre DeAngelis
> >> >> > Sent: 03-Apr-2007 13:30
> >> >> > To: XSI(at)Softimage.COM
> >> >> > Subject: FG Map Sequences
> >> >> >
> >> >> > Has anyone toyed with rendering FG maps for
whole sequences?
> >> >> >
> >> >> > We are finding that as the render
progresses, the previous file is
> >> >> > overwritten with the current one. This seem
self defeating for
> >> >> > multi-frame mode, which requires the
previous map to generate the
> >> >> > current one.
> >> >> >
> >> >> > Is this a bug or by design?
> >> >> >
> >> >> > Andre
> >> >> >
> >> >> > ---
> >> >> > Unsubscribe? Mail Majordomo(at)Softimage.COM
with the following text
> >> in
> >> >> > body:
> >> >> > unsubscribe xsi
> >> >> >
> >> >> > ---
> >> >> > Unsubscribe? Mail Majordomo(at)Softimage.COM
with the following text
> >> in
> >> >> > body:
> >> >> > unsubscribe xsi
> >> >> >
> >> >> > ---
> >> >> > Unsubscribe? Mail Majordomo(at)Softimage.COM
with the following text
> >> in
> >> >> > body:
> >> >> > unsubscribe xsi
> >> >> >
> >> >> > ---
> >> >> > Unsubscribe? Mail Majordomo(at)Softimage.COM
with the following text
> >> in
> >> >> > body:
> >> >> > unsubscribe xsi
> >> >> >
> >> >> >
> >> >> >
> >> >>
> >> >> ---
> >> >> Unsubscribe? Mail Majordomo(at)Softimage.COM
with the following text in
> >> >> body:
> >> >> unsubscribe xsi
> >> >>
> >> >> ---
> >> >> Unsubscribe? Mail Majordomo(at)Softimage.COM
with the following text in
> >> >> body:
> >> >> unsubscribe xsi
> >> >>
> >> >
> >> > ---
> >> > Unsubscribe? Mail Majordomo(at)Softimage.COM
with the following text in
> >> body:
> >> > unsubscribe xsi
> >> >
> >> > ---
> >> > Unsubscribe? Mail Majordomo(at)Softimage.COM
with the following text in
> >> body:
> >> > unsubscribe xsi
> >> >
> >> > ---
> >> > Unsubscribe? Mail Majordomo(at)Softimage.COM
with the following text in
> >> body:
> >> > unsubscribe xsi
> >>
> >>
> >> ---
> >> Unsubscribe? Mail Majordomo(at)Softimage.COM with
the following text in
> >> body:
> >> unsubscribe xsi
> >>
> >> ---
> >> Unsubscribe? Mail Majordomo(at)Softimage.COM with
the following text in
> >> body:
> >> unsubscribe xsi
> >
> >
> > ---
> > Unsubscribe? Mail Majordomo(at)Softimage.COM with
the following text in body:
> > unsubscribe xsi
>
>
> ---
> Unsubscribe? Mail Majordomo(at)Softimage.COM with
the following text in body:
> unsubscribe xsi
Invite your mail contacts to join your friends list with
Windows Live Spaces. It's easy! Try it!
|
